Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
От | Tom Lane |
---|---|
Тема | Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? |
Дата | |
Msg-id | 1727507.1620948117@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? (Dmitry Astapov <dastapov@gmail.com>) |
Ответы |
Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? |
Список | pgsql-hackers |
Dmitry Astapov <dastapov@gmail.com> writes: > Am I right in thinking that elimination the join condition is actually > quite important part of the process? > Could it possibly be the main reason for =ANY/(x IN (..)) not to be > optimized the same way? Yup. > Is it still hard when one thinks about =ANY or (column in (val1, val2, > val3, ...)) as well? Yeah. For instance, if you have WHERE a = b AND a IN (1,2,3) then yes, you could deduce "b IN (1,2,3)", but this would not give you license to drop the "a = b" condition. So now you have to figure out what the selectivity of that is after the application of the partially redundant IN clauses. I recall somebody (David Rowley, maybe? Too lazy to check archives.) working on this idea awhile ago, but he didn't get to the point of a committable patch. regards, tom lane
В списке pgsql-hackers по дате отправления: