Re: PG 16 draft release notes ready

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Erwin Brandstetter <brsaweda(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 16 draft release notes ready
Date: 2023-08-22 05:36:34
Message-ID: CAApHDvpr3CmbJDvWEVeLOkqYE0gsJuhL1YhF30Vuiryshp+vXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 22 Aug 2023 at 10:08, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Sat, Aug 19, 2023 at 04:24:48AM +0200, Erwin Brandstetter wrote:
> > I posted to pgsql-docs first, but was kindly redirected here by Jonathan:
> >
> > The release notes for Postgres 16 says here:
> > https://www.postgresql.org/docs/16/release-16.html#RELEASE-16-PERFORMANCE
> >
> > Same as here:
> > https://momjian.us/pgsql_docs/release-16.html#RELEASE-16-PERFORMANCE
> >
> > Allow window functions to use ROWS mode internally when RANGE mode is
> > specified but unnecessary (David Rowley)
>
> Yes, I didn't like "specified" myself but never returned to improve it.
> I am now using:
>
> Allow window functions to use the faster <link
> linkend="syntax-window-functions"><literal>ROWS</literal></link> mode
> internally when <literal>RANGE</literal> mode is active but unnecessary
> ------
> (David Rowley)
>
> Can that be improved?

Looks good to me.

> > Also, I was hoping to be mentioned in the release note for working this out:
> >
> > Allow window functions to use the faster ROWS mode internally when RANGE
> > mode is specified or would be default, but unnecessary (David Rowley, Erwin
> > Brandstetter)
>
> Uh, I have CC'ed David Rowley because that is unclear based on the
> commit message. I don't normally mention reviewers.

I confirm that Erwin reported in [1] that row_number() is not affected
by the ROWS/RANGE option and that ROWS performs better due to the
executor having less work to do. I am the author of the patch which
implemented that plus a few other window functions that also can
benefit from the same optimisation. Based on this, I don't see any
problems with the credits for this item as they are currently in the
release notes.

David

[1] https://postgr.es/m/CAGHENJ7LBBszxS%2BSkWWFVnBmOT2oVsBhDMB1DFrgerCeYa_DyA%40mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-08-22 05:39:48 Re: DecodeInterval fixes
Previous Message Michael Paquier 2023-08-22 05:32:06 Re: pg_rewind WAL segments deletion pitfall