Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)

[Kevin Goess <kgoess@xxxxxxxxxxx>]

Thanks for looking into it, Tom.  We're using 9.0.4, so that might indeed be the problem. What additional data (if any) would you like to see?  If you want to look into it further, I can give you schema, though I hesitate to spam the whole list.  I could also mock up some tables and see what's the smallest data set that shows the problem and send you those in a dump.

The fact that the behavior changes so radically when the limit on the joined table goes from 199 to 200 rows does make me suspect somethings not behaving the way it should.

On Tue, Mar 20, 2012 at 4:27 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:

I wrote:
> You've still got a nasty join-size estimation error:

>> ->  Nested Loop  (cost=6.18..1939.43 rows=411736 width=8) (actual
>> time=0.203..3.487 rows=35 loops=1)

> It's not apparent why that's so far off ...

What PG version is this, anyway?  It strikes me that this estimation
error might have something with the eqjoinsel bugs that we repaired
in 9.0.5.  I'm not having any luck reproducing such a bogus estimate
with current code, either, though that may just mean you've omitted
some critical info about how the tables are set up.

                       regards, tom lane

-- 
Kevin M. Goess
Software Engineer
Berkeley Electronic Press
kgoess@xxxxxxxxxxx

510-665-1200 x179
www.bepress.com

bepress: sustainable scholarly publishing