Willem Leenen <willem_leenen@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
