Horton

Re: PG 18 release notes draft committed

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Alexander Borisov <lex.borisov@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>, Jeff Davis <pgsql@j-davis.com>
Date: 2025-05-05T00:22:53Z
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. doc PG 18 relnotes: add AFTER trigger user change item

  2. doc PG 18 relnotes: modify async I/O item for other improvements

  3. doc PG 18 relnotes: split apart log_connections item

  4. doc PG 18 relnotes: move ANALYZE item,split ANALYZE/EXPLAIN item

  5. doc PG 18 relnotes: clarify multiplication item

  6. doc PG 18 relnotes: add removal details to MD5 item

  7. doc PG 18 relnotes: fix markup

  8. doc PG 18 relnotes: clarify btree skip-scan item

  9. doc PG 18 relnotes: update to current

  10. doc PG 18 relnotes: adjust CREATE SUBSCRIPTION attribution

  11. doc PG 18 relnotes: clarify btree skip scan item

  12. doc PG 18 relnotes: mv. hash joins and GROUP BY item to General

  13. Add support for runtime arguments in injection points

  14. doc PG 18 relnotes: fix missing parens for crc32c()

  15. PG 18 relnotes: adjust RETURNING new/old item

  16. doc PG 18 relnotes: adjust pg_log_backend_memory_contexts()

  17. doc PG 18 relnotes: add pg_log_backend_memory_contexts() mention

  18. doc PG 18 relnotes: adjust pgbench per-script reporting item

  19. doc PG 18 relnotes: mention GROUP SET fixes

  20. doc PG 18 relnotes: adjust partition planning item

  21. doc PG 18 relnotes: small adjustments regarding options

  22. doc PG 18 relnotes: move partition locking item to General Perf

  23. doc PG 18 relnotes: adjust partition items

  24. doc PG 18 relnotes: reword OAuth item

  25. doc PG 18 relnotes: add mention of pg_stat_reset_backend_stats()

  26. doc PG 18 relnotes: adjust hash item

  27. doc PG 18 relnotes: split partition optimizer item into two

  28. doc PG 18 relnotes: adjust COPY and REJECT_LIMIT items

  29. doc PG 18 relnotes: move and clarify constraint items

  30. doc PG 18 relnotes: add commit for cancel key and protocol neg.

  31. doc PG 18 relnotes: fix libpq wording

  32. doc PG 18 relnotes: add GROUP BY column elimination item

  33. doc PG 18 relnotes: move protocol version item to "server"

  34. doc PG 18 relnotes: adjust libpq trace & potocol version items

  35. doc PG 18 relnotes: reword and reorder items

  36. doc: Fix memory context level in pg_log_backend_memory_contexts() example.

  37. Make levels 1-based in pg_log_backend_memory_contexts()

  38. Introduce file_copy_method setting.

  39. libpq: Handle NegotiateProtocolVersion message differently

  40. Add timingsafe_bcmp(), for constant-time memory comparison

  41. Optimization for lower(), upper(), casefold() functions.

  42. Fix ALTER SUBSCRIPTION ... SET PUBLICATION ... command.

  43. Add connection establishment duration logging

  44. Modularize log_connections output

  45. Ensure that AFTER triggers run as the instigating user.

  46. Detect redundant GROUP BY columns using UNIQUE indexes

  47. Move cancel key generation to after forking the backend

On Sun, 4 May 2025 at 22:28, Alexander Borisov <lex.borisov@gmail.com> wrote:
> I'm actually a bit confused, and didn't expect such a heated discussion
> about creating an entry about my patch in Release Notes.

I definitely understand this. And to make my own opinion on this
matter extremely clear: I *do* think it's important to users, and it
should be included in the release notes.

I think there are a few things at play here why that did not happen in
Bruce his initial draft:
1. I personally think the requirement that Bruce uses for perf
improvements to make it into the changelog is too strict (see my
previous email for details)
2. Bruce is only a single person, and as such cannot read all emails
on pgsql-hackers, so he relies only on commit messages to determine
impact for release notes. The commit message for your change did not
include any details on the perf improvements that could be expected.
3. After skimming the email thread[1], it's hard for me to understand
where these perf numbers came from. And the first few results only
mention casefold performance i.e. they call the results: "casefold()
test." So, it's unclear what perf gains are expected for the other
functions mentioned in the email subject.

As for how to improve these:
1 is discussed/complained about basically every year whenever release
notes are created. I don't think we can do any better than having
those discussions. Unless someone else wants to start owning writing
the release notes, or we somehow share the burden, e.g. by having the
person that commits also write a release note entry.
2 can be improved by people including perf numbers in their commit
messages. The second way to improve is by sending feedback on the
release notes if things are missed, like you did.
3 is something you could help with I think. It would have been helpful
if you had shared the script/commands you used to get these
performance numbers. That way I could reproduce them myself. Also if
you had included some perf numbers for lower() and upper() that would
have been great too, as those are (currently) much more commonly used
than casefold(). NOTE: I might have missed the script or be wrong
about this some other way, since Jeff did not require this for
committing it. If so, please disregard.

[1]: https://www.postgresql.org/message-id/flat/7cac7e66-9a3b-4e3f-a997-42aa0c401f80%40gmail.com

> I will continue to improve Postgres.

Please do, your work is very much appreciated!