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

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