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
|
Список | 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 по дате отправления: