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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17832: ERROR: failed to apply nullingrels to a non-Var in HEAD
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c