Willem Leenen <willem_lee...@hotmail.com> writes:
> To me, i see a mismatch between the optimizer and the actual records
> retrieved in the fast SQL as well, so plan instability is a realistic
> scenario.
Well, the rowcount estimates for a recursive union are certainly
pretty bogus, but those are the same either way. The reason this looks
like a bug and not just statistical issues is that the join inside the
recursive union is done as a hash, even though that's much more
expensive (according to the estimates, not reality) than a nestloop.
Presumably the planner is failing to even consider a
nestloop-with-inner-indexscan join there, else it would have picked that
type of plan. Why it's failing is as yet unclear.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
