Re: Query Performance SQL Server vs. Postgresql - Mailing list pgsql-performance

From Robert Haas
Subject Re: Query Performance SQL Server vs. Postgresql
Date
Msg-id F70A4A8C-A76B-4139-9D24-346A1DCB2CAF@gmail.com
Whole thread Raw
In response to Re: Query Performance SQL Server vs. Postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Query Performance SQL Server vs. Postgresql
List pgsql-performance
On Nov 21, 2010, at 12:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> tv@fuzzy.cz writes:
>>> Second, I modified the work_mem setting to 2GB (reloaded config) and I see
>>> a response time of 38 seconds. Results below from EXPLAIN ANALYZE:
>
>> How did you reload the config? Using 'kill -HUP pid'? That should work
>> fine. Have you cheched 'work_mem' after the reload?
>
>> Because the explain plans are exactly the same (structure, estimated
>> costs). The really interesting bit is this and it did not change at all
>
>>   Buckets: 1024 Batches: 64  Memory Usage: 650kB
>
> If that didn't change, I'm prepared to bet that the OP didn't actually
> manage to change the active value of work_mem.

Yep.  All this speculation about slow disks and/or COALESCE strikes me as likely totally off-base. I think the original
posterneeds to run "show work_mem" right before the EXPLAIN ANALYZE to make sure the new value they set actually stuck.
There'sno reason for the planner to have used only 650kB if work_mem is set to anything >=2MB. 

...Robert

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query Performance SQL Server vs. Postgresql
Next
From: Ivan Voras
Date:
Subject: Performance under contention