Re: First draft of PG 17 release notes
Andres Freund <andres@anarazel.de>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
- 3890d90c1508 18.0 cited
-
When creating materialized views, use REFRESH to load data.
- b4da732fd64e 17.0 cited
-
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 cited
-
Avoid needless large memcpys in libpq socket writing
- c4ab7da60617 17.0 cited
-
Enhance nbtree ScalarArrayOp execution.
- 5bf748b86bc6 17.0 cited
-
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 cited
-
Combine freezing and pruning steps in VACUUM
- 6dbb490261a6 17.0 cited
-
Allow SIGINT to cancel psql database reconnections.
- cafe1056558f 17.0 cited
-
Provide API for streaming relation data.
- b5a9b18cd0bc 17.0 cited
-
Add hash support functions and hash opclass for contrib/ltree.
- 485f0aa85995 17.0 cited
-
Pull up ANY-SUBLINK with the necessary lateral support.
- 9f133763961e 17.0 cited
-
Read WAL directly from WAL buffers.
- 91f2cae7a4e6 17.0 cited
-
Introduce the dynamic shared memory registry.
- 8b2bcf3f287c 17.0 cited
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
-
Support +/- infinity in the interval data type.
- 519fc1bd9e9d 17.0 cited
-
Extend ALTER OPERATOR to allow setting more optimization attributes.
- 2b5154beab79 17.0 cited
-
Consider cheap startup paths in add_paths_to_append_rel
- a8a968a8212e 17.0 cited
Hi,
On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> Please see the email I just posted. There are three goals we have to
> adjust for:
>
> 1. short release notes so they are readable
> 2. giving people credit for performance improvements
> 3. showing people Postgres cares about performance
>
> I would like to achieve 2 & 3 without harming #1. My experience is if I
> am reading a long document, and I get to a section where I start to
> wonder, "Why should I care about this?", I start to skim the rest of
> the document.
I agree keeping things reasonably short is important. But I don't think you're
evenly applying it as a goal.
Just skimming the notes from the end, I see
- an 8 entries long pg_stat_statements section
- multiple entries about "Create custom wait events for ..."
- three entries about adding --all to {reindexdb,vacuumdb,clusterdb}.
- an entry about adding long options to pg_archivecleanup
- two entries about grantable maintenance rights, once via pg_maintain, once
per-table
- separate entries about pg_stat_reset_slru(), pg_stat_reset_shared("slru"),
If you're concerned about brevity, we can make things shorter without skipping
over most performance imporvements.
> I am particularly critical if I start to wonder, "Why
> does the author _think_ I should care about this?" becasue it feels like
> the author is writing for him/herself and not the audience.
FWIW, I think it's a good thing for somebody other than the author to have a
hand in writing a release notes entry for a change. The primary author(s) are
often too deep into some issue to have a good view of the right level of
detail and understandability.
Greetings,
Andres Freund