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

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(at)sss(dot)pgh(dot)pa(dot)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(at)bepress(dot)com

510-665-1200 x179
www.bepress.com

bepress: sustainable scholarly publishing