Re: PG 16 draft release notes ready

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 16 draft release notes ready
Date: 2023-05-21 15:52:34
Message-ID: ZGo+QtwX+iEnbRLQ@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 21, 2023 at 09:30:01PM +0900, Ian Lawrence Barwick wrote:
> 2023年5月19日(金) 5:49 Bruce Momjian <bruce(at)momjian(dot)us>:
> >
> > I have completed the first draft of the PG 16 release notes. You can
> > see the output here:
> >
> > https://momjian.us/pgsql_docs/release-16.html
> >
> > I will adjust it to the feedback I receive; that URL will quickly show
> > all updates.
>
> Hi
>
> Below are a few commits which are not referenced in the current iteration
> of the release notes, but which seem worthy of inclusion.
> Apologies if they have been previously discussed, or I'm overlooking something
> obvious.
>
> d09dbeb9b Speedup hash index builds by skipping needless binary searches
> "Testing has shown that this can improve hash index build speeds by 5-15%
> with a unique set of integer values."
>
> e09d7a126 Improve speed of hash index build.
> "This seems to be good for overall
> speedup of 5%-9%, depending on the incoming data."

For the above two items, I mention items that would change user behavior
like new features or changes that are significant enough that they would
change user behavior. For example, if a new join method increases
performance by 5x, that could change user behavior. Based on the quoted
numbers above, I didn't think "hash now faster" would be appropriate to
mention. Right?

> 594f8d377 Allow batching of inserts during cross-partition updates.
> seems reasonable to mention this as it's related to 97da48246, which
> is mentioned in the notes

I wasn't sure if that was significant, based on the above logic, but
97da48246 has a user API to control it so I mentioned that one.

> 1349d2790 Improve performance of ORDER BY / DISTINCT aggregates
> This is the basis for da5800d5, which is mentioned in the notes, but AFAICS
> the latter is an implementation fix for the former (haven't looked
> into either
> in detail though).

I have added this commit to the existing entry, thanks.

> The following are probably not headline features, but are the kind of
> behavioural
> changes I'd expect to find in the release notes (when, at some point
> in the far and
> distant future, trying to work out when they were introduced when considering
> application compatibility etc.):
>
> 13a185f54 Allow publications with schema and table of the same schema.

This seemed like a rare enough case that I did not add it.

> 2ceea5adb Accept "+infinity" in date and timestamp[tz] input.

I have this but didn't add that commit, added.

> d540a02a7 Display the leader apply worker's PID for parallel apply workers.

Parallelism of apply is a new feature and I don't normally mention
output _additions_ that are related to new features.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2023-05-21 15:53:04 Re: Naming of gss_accept_deleg
Previous Message Tom Lane 2023-05-21 15:45:24 Re: createuser --memeber and PG 16