Horton

Re: First draft of PG 17 release notes

Peter Geoghegan <pg@bowt.ie>

View thread
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-05-21T17:06:43Z
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 12:27 PM Andres Freund <andres@anarazel.de> wrote:
> > I agree the impact of performance improvements are often greater than
> > the average release note item.  However, if people expect Postgres to be
> > faster, is it important for them to know _why_ it is faster?
>
> Yes, it very often is.

Is it important for them to even read the release notes?

Bruce's arguments against listing performance items more often/with
greater prominence could just as easily be applied to other types of
features, in other areas. Performance is a feature (or a feature
category) -- no better or worse than any other category of feature.

> Performance improvements typically aren't "make
> everything 3% faster", they're more "make this special thing 20%
> faster". Without know what got faster, users don't know if
> a) the upgrade will improve their production situation
> b) they need to change something to take advantage of the improvement

Another important category of performance improvement is "make the
thing that was just unusable usable, for the first time ever".

Sometimes the baseline is unreasonably slow, so an improvement
effectively allows you as a user to do something that just wasn't
possible on previous versions. Other times it's addressed at something
that was very scary, like VACUUMs that need multiple rounds of index
vacuuming. Multiple rounds of index vacuuming are just woefully,
horribly inefficient, and are the single individual thing that can
make things far worse. Even if you didn't technically have that
problem before now, you did have the problem of having to worry about
it. So the work in question has sanded-down this really nasty sharp
edge. That's a substantial quality of life improvement for many users.

In short, many individual performance improvements are best thought of
as qualitative improvements, rather than quantitative improvements.

It doesn't help that there is a kind of pressure to present them as
quantitative improvements. For example, I was recently encouraged to
present my own Postgres 17 B-Tree work internally using some kind of
headline grabbing measure like "6x faster". That just seems silly to
me. I can contrive a case where it's faster by an arbitrarily large
amount. Much like how a selective index scan can be arbitrarily faster
than a sequential scan. Again, a qualitative improvement.

-- 
Peter Geoghegan