From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, jeremyevans0(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |
Date: | 2022-05-26 08:22:43 |
Message-ID: | CAMbWs49oxGmJT-hKWzfBpo-XYtFCTPSOUAmsniJCMUtnXp8X7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, May 26, 2022 at 1:38 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Thu, 26 May 2022 at 16:34, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > On Thu, May 26, 2022 at 12:13 PM Richard Guo <guofenglinux(at)gmail(dot)com>
> wrote:
> >>
> >>
> >> On Thu, May 26, 2022 at 11:47 AM David Rowley <dgrowleyml(at)gmail(dot)com>
> wrote:
> >>>
> >>> The problem is that the qual pushdown stuff all happens in
> >>> set_subquery_pathlist() before we call subquery_planner() for the
> >>> subquery. We don't yet have a PlannerInfo made for the subquery when
> >>> we call check_and_push_window_quals(). We don't really have any other
> >>> means to communicate to subquery_planner() what the run conditions are
> >>> for the given Query object. Plus, we *do* really need to know what the
> >>> runConditions are before we call subquery_planner() so that those
> >>> conditions can be properly tagged onto WindowAggPaths. I don't really
> >>> think it would be right to pluck those from the PlannerInfo when we
> >>> later call create_plan(). That wouldn't leave us any opportunity to do
> >>> any costing related stuff with run conditions if we decide to do that
> >>> later.
> >>
> >>
> >> The remove_unused_subquery_outputs() also happens before we call
> >> subquery_planner() for the subquery. Cann't we just store the attnos
> >> used in window quals that are pushed down to runConditions in the
> >> PlannerInfo of the upper query?
> >
> >
> > Ah, your point is to move runConditions also out of WindowClause and
> > store them in PlannerInfo, right? That's indeed not an easy job.
>
> Yeah, I was aiming for a way to have it so the planner didn't
> vandalise WindowClause.
>
> I've attached a patch which fixes the bug and does not require any
> further modifications to WindowClause.
>
The patch looks sane to me, expect that line 122 in the patch introduces
a whitespace-only line.
BTW, surprised that param 'attno' in find_window_run_conditions() is not
used before.
So after this fix, do we plan to further move runConditions out of
WindowClause so that we don't need to modify the input parse tree?
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-05-26 08:44:17 | Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |
Previous Message | Noah Misch | 2022-05-26 05:50:47 | Re: Extension pg_trgm, permissions and pg_dump order |