On Tue, Dec 4, 2012 at 3:03 PM, <postgresql@foo.me.uk> wrote:
>
> Though that doesn't account for the 70x difference between the speed of the
> two queries in actuality given a pretty similar expected speed (does it?).
> It does go some way to explaining why a bad choice of plan was made.
I still don't think it does. I still think the problem is the GUC settings.
The slow plan joins in a way that processes all 3M rows in both sides
of the join, and pg knows it.
The fast plan only processes 5k of them. And pg knows it. Why is it
choosing to process 3M rows?
If there's negative correlation, it only means less rows will be
produced, but the nested loop and and the right-hand index scan still
happens.
