From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mathieu De Zutter <mathieu@dezutter.org>
cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Query plan change with multiple elements in IN clause
In-reply-to: 
 <CAH7GKCzV_ZSBodUaT9ui406o-0Ak9WNHWW=yCMThj8CE_QJXQQ@mail.gmail.com>
References: 
 <CAH7GKCzV_ZSBodUaT9ui406o-0Ak9WNHWW=yCMThj8CE_QJXQQ@mail.gmail.com>
Comments: In-reply-to Mathieu De Zutter <mathieu@dezutter.org>
 message dated "Fri, 30 Aug 2013 11:05:46 +0200"
Date: Fri, 30 Aug 2013 10:00:28 -0400
Message-ID: <5899.1377871228@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Mathieu De Zutter <mathieu@dezutter.org> writes:
> The problem is that this join is performing very badly when more than one
> work is involved. It chooses a plan that is orders of magnitude slower.

> I have attached
> - The (simplified) table definitions
> - The (simplified) view
> - Two queries with explain analyze plan: "IN (1)" => fast, "IN (1,3)" =>
> slow
> - postgresql.conf

The reason you get a nice plan in the first case is that "w.id in (1)"
is treated as "w.id = 1", and then there is logic that combines that with
"w.id = wps.id" to conclude that we can synthesize a condition "wps.id = 1".
None of that happens when there's more than one IN item, because it's not
an equality operator anymore.

You might be able to do something like
    JOIN (VALUES (1),(3)) foo(x) ON w.id = foo.x

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance