From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, 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-25 22:39:46 |
Message-ID: | 2026718.1653518386@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Maybe a better fix is to add a new Bitmapset field to WindowClause and
> have find_window_run_conditions() record the attno in that field when
> it appends the new runCondition to the runCondition field.
> remove_unused_subquery_outputs() can just bms_add_members that field
> to attrs_used. This just means having to add a field to WindowClause
> post-beta. Is that going to be a problem?
It'd mean a forced initdb, which is not great, but unless 0ff20288e
gets reverted there'd be no additional impact on beta testers.
A bigger problem with what you describe is that I don't really think
the planner should be mucking with the input parse tree like that.
Can't we retain this information somewhere else instead, in storage
associated with the PlannerInfo?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | jam paydavousi | 2022-05-25 22:59:27 | Re: BUG #17498: Receive Failed: (error code 1) when importing any csv file from pgAdmin with no explanations |
Previous Message | David Rowley | 2022-05-25 22:33:19 | Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function |