Re: [PERFORM] postmaster consuming /lots/ of memory with hash aggregate. why?

2010-11-23 Thread Robert Haas
On Fri, Nov 12, 2010 at 11:12 AM, Pavel Stehule wrote: > if I remember well, you can set a number of group by ALTER TABLE ALTER > COLUMN SET n_distinct = .. > > maybe you use it. I'm not sure where the number 40,000 is coming from either, but I think Pavel's suggestion is a good one. If you're g

Re: [PERFORM] Performance under contention

2010-11-23 Thread Ivan Voras
On 24 November 2010 01:11, Craig Ringer wrote: > On 11/22/2010 11:38 PM, Ivan Voras wrote: >> It looks like a hack (and one which is already implemented by connection >> pool software); the underlying problem should be addressed. > > My (poor) understanding is that addressing the underlying probl

Re: [PERFORM] Performance under contention

2010-11-23 Thread Craig Ringer
On 11/22/2010 11:38 PM, Ivan Voras wrote: On 11/22/10 16:26, Kevin Grittner wrote: Ivan Voras wrote: On 11/22/10 02:47, Kevin Grittner wrote: Ivan Voras wrote: After 16 clients (which is still good since there are only 12 "real" cores in the system), the performance drops sharply Yet anoth

Re: [PERFORM] Query Performance SQL Server vs. Postgresql

2010-11-23 Thread Merlin Moncure
On Mon, Nov 22, 2010 at 7:12 PM, Humair Mohammed wrote: > I did some further analysis and here are the results: > work_mem;response_time > 1MB;62 seconds > 2MB;2 seconds > 4MB;700 milliseconds > 8MB;550 milliseconds > In all cases shared_buffers were set to the default value of 32MB. As you > can

Re: [PERFORM] Query Performance SQL Server vs. Postgresql

2010-11-23 Thread Humair Mohammed
I did some further analysis and here are the results: work_mem;response_time1MB;62 seconds2MB;2 seconds4MB;700 milliseconds8MB;550 milliseconds In all cases shared_buffers were set to the default value of 32MB. As you can see the 1 to 2 MB jump on the work_mem does wonders. I probably don't need