Re: Planning for improved versions of IN/NOT IN - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Planning for improved versions of IN/NOT IN
Date
Msg-id 053e01c29686$46aaadd0$6500a8c0@internal
Whole thread Raw
In response to Planning for improved versions of IN/NOT IN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Planning for improved versions of IN/NOT IN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The difficulty is that it's not clear how to choose one of these four
> ways, short of planning the *entire* query from scratch all four ways :-(.
> This seems pretty grim.  Approaches #2 and #3 could be handled as local
> transformations of the WHERE clause, but we couldn't choose which to use
> very well if we don't yet know how many outer rows the WHERE clause will
> be executed for.  Approach #1 is really planning a completely different
> query --- one with an extra FROM-item --- and there's not going to be
> all that much commonality in the computations, unless we restrict where
> the added FROM-item can be joined to the others, which'd more or less
> defeat the purpose.

What about in the case of a scalar subquery eg. SELECT x IN
(1,2,3,4,54,56,6), when there maybe hundreds of scalars?

Chris



pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: v7.3 Packaged ...
Next
From: Bruce Momjian
Date:
Subject: Re: v7.3 Packaged ...