Thanks for the tips. I would move to LINUX if it was an option :( I will bring the numbers down and do some benchmarking and tests to find out what I can get away with on this system. Thanks again, Jeremy -----Original Message----- From: Scott Marlowe [mailto:scott.marlowe@xxxxxxxxx] Sent: Wednesday, August 25, 2010 5:34 PM To: Jeremy Palmer Cc: Tom Lane; Magnus Hagander; pgsql-general@xxxxxxxxxxxxxx; Alvaro Herrera Subject: Re: Win32 Backend Cash - pre-existing shared memory block is still in use I would be WAY cheaper in time and effort, to just build a simple 64 bit linux box, toss 16 or 32 Gigs in it, and put your reporting db on there. Trying to do "big memory" things in windows is, at least for now, a net loss. On Tue, Aug 24, 2010 at 11:30 PM, Jeremy Palmer <JPalmer@xxxxxxxxxxxx> wrote: > Yeah that's what stated here: http://technet.microsoft.com/en-us/library/ms189334.aspx > > But only if I add /3gb switch to the kernel boot parameters > > -----Original Message----- > From: Scott Marlowe [mailto:scott.marlowe@xxxxxxxxx] > Sent: Wednesday, August 25, 2010 5:28 PM > To: Tom Lane > Cc: Jeremy Palmer; Magnus Hagander; pgsql-general@xxxxxxxxxxxxxx; Alvaro Herrera > Subject: Re: Win32 Backend Cash - pre-existing shared memory block is still in use > > On Tue, Aug 24, 2010 at 11:23 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Scott Marlowe <scott.marlowe@xxxxxxxxx> writes: >>> 512M is still REALLY high for a 32 bit postgresql. Have you tried >>> something in the 16Meg range? >> >> Cutting his value for shared_buffers (currently about 800MB) might be >> wise too. I'm not sure what the effectively available address space >> for a win32 process is, but if there's any inefficiency in the way >> the address space is laid out, those numbers could be enough to be >> trouble. > > I believe it's limited to 3Gigs. > ______________________________________________________________________________________________________ > > This message contains information, which is confidential and may be subject to legal privilege. > If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. > If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@xxxxxxxxxxxx) and destroy the original message. > LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. > > Thank you. > ______________________________________________________________________________________________________ > -- To understand recursion, one must first understand recursion. ______________________________________________________________________________________________________ This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@xxxxxxxxxxxx) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank you. ______________________________________________________________________________________________________ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
