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

[Jan Michel <Jan@xxxxxxxxxxxxxxx>]

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