Re: Planning for improved versions of IN/NOT IN

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: Planning for improved versions of IN/NOT IN
Дата
Msg-id 053e01c29686$46aaadd0$6500a8c0@internal
обсуждение исходный текст
Ответ на Planning for improved versions of IN/NOT IN  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Planning for improved versions of IN/NOT IN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: v7.3 Packaged ...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: v7.3 Packaged ...