Re: Window Function "Run Conditions"

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Window Function "Run Conditions"
Дата
Msg-id CAApHDvp8PSY3GJXNzzrBPJtzRgQ-C85OPy-bypFGmwaT3AjCjQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Window Function "Run Conditions"  (Andy Fan <zhihui.fan1213@gmail.com>)
Ответы Re: Window Function "Run Conditions"  (Andy Fan <zhihui.fan1213@gmail.com>)
Re: Window Function "Run Conditions"  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: replay of CREATE TABLESPACE eats data at wal_level=minimal
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side