Re: Window Function "Run Conditions"

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Window Function "Run Conditions"
Date: 2022-03-17 04:04:03
Message-ID: CADkLM=eysxtm6fqquPa3fZKQVB_8wvXA_ooPB5iFz4e-0PdV7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 15, 2022 at 5:24 PM Greg Stark <stark(at)mit(dot)edu> wrote:

> This looks like an awesome addition.
>
> I have one technical questions...
>
> Is it possible to actually transform the row_number case into a LIMIT
> clause or make the planner support for this case equivalent to it (in
> which case we can replace the LIMIT clause planning to transform into
> a window function)?
>
> The reason I ask is because the Limit plan node is actually quite a
> bit more optimized than the general window function plan node. It
> calculates cost estimates based on the limit and can support Top-N
> sort nodes.
>
> But the bigger question is whether this patch is ready for a committer
> to look at? Were you able to resolve Andy Fan's bug report? Did you
> resolve the two questions in the original email?
>

+1 to all this

It seems like this effort would aid in implementing what some other
databases implement via the QUALIFY clause, which is to window functions
what HAVING is to aggregate functions.
example:
https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#qualify_clause

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-03-17 05:18:38 Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Previous Message Thomas Munro 2022-03-17 03:34:30 Re: pg_tablespace_location() failure with allow_in_place_tablespaces