Re: Query Performance SQL Server vs. Postgresql
От | Robert Haas |
---|---|
Тема | Re: Query Performance SQL Server vs. Postgresql |
Дата | |
Msg-id | F70A4A8C-A76B-4139-9D24-346A1DCB2CAF@gmail.com обсуждение исходный текст |
Ответ на | Re: Query Performance SQL Server vs. Postgresql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Query Performance SQL Server vs. Postgresql
|
Список | 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 по дате отправления: