From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Window Function "Run Conditions" |
Date: | 2021-08-19 06:35:27 |
Message-ID: | CAApHDvp8PSY3GJXNzzrBPJtzRgQ-C85OPy-bypFGmwaT3AjCjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 19 Aug 2021 at 00:20, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-08-19 06:51:09 | Re: Skipping logical replication transactions on subscriber side |
Previous Message | Noah Misch | 2021-08-19 05:32:10 | Re: replay of CREATE TABLESPACE eats data at wal_level=minimal |