Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function

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

In response to

Responses

Browse pgsql-bugs by date

  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