Re: One query run twice in parallel results in huge performance decrease

Поиск
Список
Период
Сортировка
От Jan Michel
Тема Re: One query run twice in parallel results in huge performance decrease
Дата
Msg-id 529E3C9F.8070101@mueschelsoft.de
обсуждение исходный текст
Ответ на Re: One query run twice in parallel results in huge performance decrease  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance

Jeff Janes wrote:
I think what I would do next is EXPLAIN (without ANALYZE) one of the queries repeatedly, say once a second, while the other query either runs or doesn't run repeatedly, that is the other query runs for 11 minutes (or however it takes to run), and then sleeps for 11 minutes in a loop.  Then you can see if the explain plan differs very reliably, and if the transition is exactly aligned with the other starting and stopping or if it is offset.

Hi Jeff,
I ran the one analyze over and over again as you proposed - but the result never changed.
But I think I found a solution for the problem. While browsing through the manual I found a statement about GIN indexes:
"For tables with GIN indexes, VACUUM (in any form) also completes any pending index insertions, by moving pending index entries to the appropriate places in the main GIN index structure". I use a gist and no gin index, but I tried to vacuum the (freshly filled) table, and it helped. It seems that the planer is simply not aware of the existence of the index although I run an analyze on the table right before the query.

Thank you all for your suggestions!
Jan

В списке pgsql-performance по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Parallel Select query performance and shared buffers
Следующее
От: Metin Doslu
Дата:
Сообщение: Re: [HACKERS] Parallel Select query performance and shared buffers