Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: xinwen(at)stu(dot)scu(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
Date: 2023-03-12 21:19:45
Message-ID: CAApHDvoaExj=YiOJ4PpbshPnOV5d95HQAGJeh44HPQW6Nns-8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, 12 Mar 2023 at 06:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-03-12 21:43:55 Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c
Previous Message Tom Lane 2023-03-12 17:02:41 Re: BUG #17832: ERROR: failed to apply nullingrels to a non-Var in HEAD