Horton

Re: First draft of PG 17 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-05-20T18:40:42Z
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 Mon, May 20, 2024 at 02:35:37PM -0400, Melanie Plageman wrote:
> On Sat, May 18, 2024 at 11:13 AM Bruce Momjian <bruce@momjian.us> 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 agree with all three of these goals. I would even add to 3 "show
> users Postgres is addressing their performance complaints". That in
> particular makes me less excited about having a  "generic performance
> release note item saying performance has been improved in the
> following areas" (from your other email). I think that describing the
> specific performance improvements is required to 1) allow users to
> change expectations and configurations to take advantage of the
> performance enhancements 2) ensure users know that their performance
> concerns are being addressed.

Well, as you can see, doing #2 & #3 works against accomplishing #1.

> > 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 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.
> 
> I see what you are saying. We don't want to just end up with the whole
> git log in the release notes. However, we know that not all users will
> care about the same features. As someone said somewhere else in this
> thread, presumably hackers spend time on features because some users
> want them.

I think we need as a separate section about performance improvements
that don't affect specific workloads.  Peter Eisentraut created an
Acknowledgements section at the bottom of the release notes, similar to
#2 above, so maybe someone else can add a performance internals section
too.

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

  Only you can decide what is important to you.