Re: apply outer->inner join optimisation to OR clauses
От | Tom Lane |
---|---|
Тема | Re: apply outer->inner join optimisation to OR clauses |
Дата | |
Msg-id | 27683.1052058448@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: apply outer->inner join optimisation to OR clauses (Bradley Baetz <bbaetz@acm.org>) |
Список | pgsql-patches |
Bradley Baetz <bbaetz@acm.org> writes: > Or are we guaranteed that there wont' be OR/AND expressions > inside a NOT, because they will have always been expanded? No, we're not, because the CNF-ifying code is optional. If you study the heuristics in prepqual.c you could doubtless devise a query that has such an expression somewhere in it. Even if that was a safe assumption today, writing code that would fail in as subtle a way as this when presented with such a tree won't do. The optimizer gets revamped constantly, and so I don't want to see any assumptions that fragile embedded into pieces of it. > Do we agree that if the thing inside the NOT is a single expression, > then what I've doing is safe? IS it safe even if theres and/or involved > as the argument to a (strict) operator? I'm going to take the position "fix it right or don't touch it at all". The routine as it stands does what it was intended to do. If you want to invest the effort to take it to the next level of intelligence, great --- but let's not put in a half-baked attempt. regards, tom lane
В списке pgsql-patches по дате отправления: