Allan Wang <allanvv@gmail.com> writes:
> On Wed, 2005-06-08 at 13:02 -0400, Tom Lane wrote:
>> Are you running 7.4.8 or 8.0.2 or later?
> I'm running 8.0.2 on Gentoo.
Oh, OK [ looks again ... ] I read the join backward, the issue I was
concerned about would've applied to a right join there not left.
The seqscan vs indexscan difference is a red herring: if you look at the
explain output, the only thing that changes to an indexscan is the scan
on cities, which is only two rows and is not taking any time anyway.
The thing that is taking a long time (or not) is the indexscan over
players. The planner is expecting that to stop short of completion
(presumably based on comparing the maximum values of playerid in
the two tables) --- and in one plan it does so, so the planner's
logic is apparently correct.
Are there any NULLs in c.playerid? We found an executor issue recently
that it would not figure out it could stop the scan if there was a NULL
involved.
regards, tom lane
