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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Goess <kgoess(at)bepress(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-general(at)postgresql(dot)org
Subject: Re: WHERE IN (subselect) versus WHERE IN (1,2,3,)
Date: 2012-03-19 14:28:38
Message-ID: 25285.1332167318@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Kevin Goess <kgoess(at)bepress(dot)com> writes:
> On Mon, Mar 19, 2012 at 9:24 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>wrote:
>> That means that your statistics are not accurate.

> Aha, thanks, that explains why my test table with one row was so bad. But
> even with all freshly ANALYZE'd tables, I still see the query reverting to
> a sequential scan on that big contexts table once the number of rows in the
> subselect goes over 199. Here's a simplified version that demonstrates the
> problem.

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 ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Janning Vygen 2012-03-19 14:45:28 Re: Anonymized database dumps
Previous Message Bill Moran 2012-03-19 12:22:57 Re: Anonymized database dumps