Horton

Re: PG 18 release notes draft committed

Alexander Borisov <lex.borisov@gmail.com>

View thread
From: Alexander Borisov <lex.borisov@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>, Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-04T20:28:44Z
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

04.05.2025 12:19, Jelte Fennema-Nio wrote:
> On Sun, 4 May 2025 at 03:21, Bruce Momjian <bruce@momjian.us> wrote:
>> So the logic is something I posted to this thread already:
>>
>>          So, a few things.  First, these set of commits was in a group of 10 that
>>          I added since there have been complaints in the past that optimizer
>>          improvements were not listed and therefore patch authors were not given
>>          sufficient credit.  That means the 209 item count for PG 18 is 10 higher
>>          than my normal filtering would produce.
>>
>>          Second, looking at the items, these are a case of "X is faster", which
>>          we don't normally mention in the release notes.  We normally mention
>>          "faster" when it is so much faster that use cases which were not
>>          possible before might be possible now, so it is recommended to retest.
>>          That is what I saw this grouped item as, whereas I don't think the
>>          individual items meet that criteria.
> 
> Let me start off the yearly thread of people saying they disagree with
> this filtering logic. I think there's an important utility of the
> Release Notes that these logic is not covering well:
> 
> Many people read the release notes to see if upgrading is worth the
> hassle & risk for them specifically. The aggregate of some small
> performance improvements that apply to their queries could very well
> push them over the edge. These performance improvements don't need to
> "allow any new use cases" for that to be the case.
> 
> The filtering that you currently do makes the release notes much less
> useful for people using the release notes for this purpose. Users
> might very well care more about ~10% perf improvement for a feature
> they use heavily, than all of the newly added SQL syntax combined.
> 
>> So, users are interested in performance in the sense it makes use cases
>> possible, and if your commit is making the case folding useful, we
>> should mention it in the release notes.  I don't think making it
>> separate would fit though.
> 
> For this specific commit, I think if it had only changed the
> performance of casefold(), then I'd agree that it should be grouped
> with the casefold addition in the release notes. My reasoning would be
> that there's no "diff" in performance since the previous release,
> because the function did not exist in the previous release. So the
> perf improvements are simply part of the "initial implementation" of
> casefold from a user perspective.
> 
> However since this commit also impacts the very commonly used lower()
> and upper() functions, I think that it would make sense if it got its
> own entry. It's neither clear for me from the commit message nor the
> skimming the original thread, whether the perf improvement numbers
> listed by Alexander also apply to lower() and upper(), or if they only
> apply to casefold():
> 
> On Sun, 4 May 2025 at 00:32, Alexander Borisov <lex.borisov@gmail.com> wrote:
>> ASCII by ≈10%
>> Cyrillic by ≈80%
>> Unicode in general by ≈30%
> 
> If they apply the lower() and upper() I definitely think this patch
> deserves a place in "General Performance".

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 thought I had made significant Unicode improvements to Postgres.
Namely, significantly reduce the object file size for Unicode Case, and
most importantly increased performance.
Thanks to my approach/algorithm, all Unicode Case related functions got
a significant boost.
Namely: lower(), upper(), casefold(). I have already given the figures.
Why casefold() is the one that got caught here is not clear to me, I
have nothing to do with the implementation of this function.
I improved the overall Unicode Case algorithm, which caused a boost in
all of the listed functions.

I thought it would be useful for users to know that Postgres is
improving in the performance direction, especially in such functions
that are very often used by users to compare text by bringing it to a
certain case.

The discussion made me realize that it's not that important.
I'm not insisting. If it really doesn't matter to users, then it's not
worth discussing.


Thank you for your attention.
I will continue to improve Postgres.

-- 
Regards,
Alexander Borisov