Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
От | David Rowley |
---|---|
Тема | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c |
Дата | |
Msg-id | CAApHDvoaExj=YiOJ4PpbshPnOV5d95HQAGJeh44HPQW6Nns-8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
|
Список | pgsql-bugs |
On Sun, 12 Mar 2023 at 06:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Why can't we simply *remove* all this logic from subquery pushdown? > > I would expect that what happens in useful cases is that we push down > the (safe) qual and then during planning of the subquery we see a WHERE > clause matching the window run condition and work with that. So this > all seems redundant, quite aside from being faulty. hmm, sorry, I can't quite make sense of that. It is only possible to either leave such quals in the outer query in the WHERE clause or make them run conditions of some WindowClause in the subquery. They can never be legally in the WHERE clause of the subquery as window functions cannot be evaluated in the WHERE clause. So I'm not really sure what the point of temporarily putting it in the subqueries WHERE clause would be if we just later unconditionally move it to become a WindowClause run condition. If we're pushing it down, then we need to validate that the qual definitely can become a run condition qual, why not just make it that when it passes the validation? David
В списке pgsql-bugs по дате отправления: