Horton

Re: First draft of PG 17 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@anarazel.de>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-05-22T22:33:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

  2. When creating materialized views, use REFRESH to load data.

  3. Revert temporal primary keys and foreign keys

  4. Avoid needless large memcpys in libpq socket writing

  5. Enhance nbtree ScalarArrayOp execution.

  6. Introduce a non-recursive JSON parser

  7. Combine freezing and pruning steps in VACUUM

  8. Allow SIGINT to cancel psql database reconnections.

  9. Provide API for streaming relation data.

  10. Add hash support functions and hash opclass for contrib/ltree.

  11. Pull up ANY-SUBLINK with the necessary lateral support.

  12. Read WAL directly from WAL buffers.

  13. Introduce the dynamic shared memory registry.

  14. Add macros for looping through a List without a ListCell.

  15. Support +/- infinity in the interval data type.

  16. Extend ALTER OPERATOR to allow setting more optimization attributes.

  17. Consider cheap startup paths in add_paths_to_append_rel

On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> 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

What item did you want to remove?  Those are all user-visible changes.

> - multiple entries about "Create custom wait events for ..."

Well, those are all in different sections, so how can they be merged,
unless I create a "wait event section", I guess.

> - three entries about adding --all to {reindexdb,vacuumdb,clusterdb}.

The problem with merging these is that the "Specifically, --all can now
be used with" is different for all three of them.

> - an entry about adding long options to pg_archivecleanup

Well, that is a user-visible change.  Should it not be listed?

> - two entries about grantable maintenance rights, once via pg_maintain, once
>   per-table

Well, one is a GRANT and another is a role, so merging them seemed like
it would be too confusing.

> - separate entries about pg_stat_reset_slru(), pg_stat_reset_shared("slru"),

They are different functions with different detail text.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.