Philipp Reisner <philipp.reisner@linbit.com> writes:
> Version: 8.0.2
I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0.
> Is this bug-report of any use so far ?
Not a lot. You need to find out what the difference is between the
cases where the query runs quickly and those where it doesn't. I'm
betting that the planner is choosing a very bad plan in the slow cases,
but there's not a lot of evidence here to show what or why.
The explain analyze output shows two levels of hash join underneath
four levels of nestloop join, whereas the stack trace looks like there
are five levels of nestloop and only one hash. So this is some evidence
that a different plan is being used in the slow cases. The stack trace
doesn't provide nearly enough info about what that plan is, though.
Do you have geqo_threshold set to less than its default value? Do you
sometimes execute the query with different sets of parameters? Either
of these might lead to changes of plan.
regards, tom lane