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

From David Rowley
Subject Re: Window Function "Run Conditions"
Date
Msg-id CAApHDvoe=MqH66pDWynUtdammYHiB8m+zE7LvL_CGuxm1yK4BQ@mail.gmail.com
Whole thread Raw
In response to Re: Window Function "Run Conditions"  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Window Function "Run Conditions"  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Wed, 23 Mar 2022 at 11:24, David Rowley <dgrowleyml@gmail.com> wrote:
> I think it's safer to just disable the optimisation when there are
> multiple window clauses.  Multiple matching clauses are merged
> already, so it's perfectly valid to have multiple window functions,
> it's just they must share the same window clause.  I don't think
> that's terrible as with the major use case that I have in mind for
> this, the window function is only added to limit the number of rows.
> In most cases I can imagine, there'd be no reason to have an
> additional window function with different frame options.

I've not looked into the feasibility of it, but I had a thought that
we could just accumulate all the run-conditions in a new field in the
PlannerInfo then just tag them onto the top-level WindowAgg when
building the plan.

I'm just not sure it would be any more useful than what the v3 patch
is currently doing as intermediate WindowAggs would still need to
process all rows.  I think it would only save the window function
evaluation of the top-level WindowAgg for rows that don't match the
run-condition.  All the supported window functions are quite cheap, so
it's not a huge saving. I'd bet there would be example cases where it
would be measurable though.

David



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Window Function "Run Conditions"
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH] Add native windows on arm64 support