Re: WHERE IN (subselect) versus WHERE IN (1,2,3,) - Mailing list pgsql-general

From Kevin Goess
Subject Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)
Date
Msg-id CABZkbxhD-h5XzcccVFt4NArmj6vEqoiZkMDvCQ2=huNK5DTzXw@mail.gmail.com
Whole thread Raw
In response to Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)
List pgsql-general
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@sss.pgh.pa.us> 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@bepress.com

510-665-1200 x179
www.bepress.com

bepress: sustainable scholarly publishing  

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)
Next
From: Stefan Keller
Date:
Subject: Re: How to convert integer to string in functions