Re: Window Function "Run Conditions" - Mailing list pgsql-hackers

From David Rowley
Subject Re: Window Function "Run Conditions"
Date
Msg-id CAApHDvp8PSY3GJXNzzrBPJtzRgQ-C85OPy-bypFGmwaT3AjCjQ@mail.gmail.com
Whole thread Raw
In response to Re: Window Function "Run Conditions"  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: Window Function "Run Conditions"  (Andy Fan <zhihui.fan1213@gmail.com>)
Re: Window Function "Run Conditions"  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, 19 Aug 2021 at 00:20, Andy Fan <zhihui.fan1213@gmail.com> wrote:
> In the current master, the result is:
>
>  empno | salary | c | dr
> -------+--------+---+----
>      8 |   6000 | 4 |  1

> In the patched version, the result is:
>
>  empno | salary | c | dr
> -------+--------+---+----
>      8 |   6000 | 1 |  1

Thanks for taking it for a spin.

That's a bit unfortunate.  I don't immediately see how to fix it other
than to restrict the optimisation to only apply when there's a single
WindowClause. It might be possible to relax it further and only apply
if it's the final window clause to be evaluated, but in those cases,
the savings are likely to be much less anyway as some previous
WindowAgg will have exhausted all rows from its subplan.  Likely
restricting it to only working if there's 1 WindowClause would be fine
as for the people using row_number() for a top-N type query, there's
most likely only going to be 1 WindowClause.

Anyway, I'll take a few more days to think about it before posting a fix.

David



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side