To: allanvv@gmail.com
Cc: pgsql-performance@postgreSQL.org
Subject: Re: Performance problems, bad estimates and plan 
In-reply-to: <1118250631.3454.6.camel@localhost> 
References: <1118243044.3454.3.camel@localhost>
 <4362.1118250155@sss.pgh.pa.us>
	<1118250631.3454.6.camel@localhost>
Comments: In-reply-to Allan Wang <allanvv@gmail.com>
	message dated "Wed, 08 Jun 2005 13:10:31 -0400"
Date: Wed, 08 Jun 2005 13:39:16 -0400
Message-ID: <9065.1118252356@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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