Re: DELETE performance problem
От | marcin mank |
---|---|
Тема | Re: DELETE performance problem |
Дата | |
Msg-id | b1b9fac60911250722n3a55c9a1v8a61657f112e9f2a@mail.gmail.com обсуждение исходный текст |
Ответ на | DELETE performance problem (Luca Tettamanti <kronos.it@gmail.com>) |
Ответы |
Re: DELETE performance problem
|
Список | pgsql-performance |
On Tue, Nov 24, 2009 at 2:37 PM, Luca Tettamanti <kronos.it@gmail.com> wrote: > -> HashAggregate (cost=1031681.15..1033497.20 rows=181605 width=8) (a > ctual time=571807.575..610178.552 rows=26185953 loops=1) This is Your problem. The system`s estimate for the number of distinct annotation_ids in t2 is wildly off. The disk activity is almost certainly swapping (You can check it iostat on the linux machine). Can You try "analyze t2" just before the delete quety? maybe try raising statistics target for the annotation_id column. If all else fails, You may try "set enable_hashagg to false" just before the query. Greetings Marcin Mańk Greetings Marcin Mańk
В списке pgsql-performance по дате отправления: