Re: PG 18 release notes draft committed
amit <amitlangote09@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc PG 18 relnotes: add AFTER trigger user change item
- 73e26cbeb592 18.0 landed
-
doc PG 18 relnotes: modify async I/O item for other improvements
- 03c53a73141a 18.0 landed
-
doc PG 18 relnotes: split apart log_connections item
- a1de1b0833b8 18.0 landed
-
doc PG 18 relnotes: move ANALYZE item,split ANALYZE/EXPLAIN item
- bf6034d00dd4 18.0 landed
-
doc PG 18 relnotes: clarify multiplication item
- c861092b0e0f 18.0 landed
-
doc PG 18 relnotes: add removal details to MD5 item
- 3e782ca32225 18.0 landed
-
doc PG 18 relnotes: fix markup
- 08b8aa174840 18.0 landed
-
doc PG 18 relnotes: clarify btree skip-scan item
- 44ce4e1593b1 18.0 landed
-
doc PG 18 relnotes: update to current
- 1ca583f6c0f9 18.0 landed
-
doc PG 18 relnotes: adjust CREATE SUBSCRIPTION attribution
- 883339c170d1 18.0 landed
-
doc PG 18 relnotes: clarify btree skip scan item
- 7ddfac79f2cd 18.0 landed
-
doc PG 18 relnotes: mv. hash joins and GROUP BY item to General
- 99ddf8615c21 18.0 landed
-
Add support for runtime arguments in injection points
- 371f2db8b05e 18.0 cited
-
doc PG 18 relnotes: fix missing parens for crc32c()
- 89372d0aaa4a 18.0 landed
-
PG 18 relnotes: adjust RETURNING new/old item
- 9d710a1ac091 18.0 landed
-
doc PG 18 relnotes: adjust pg_log_backend_memory_contexts()
- 9fef27a83b31 18.0 landed
-
doc PG 18 relnotes: add pg_log_backend_memory_contexts() mention
- f8d49aa130b2 18.0 landed
-
doc PG 18 relnotes: adjust pgbench per-script reporting item
- 69aca072ebf6 18.0 landed
-
doc PG 18 relnotes: mention GROUP SET fixes
- 3bd5271729c5 18.0 landed
-
doc PG 18 relnotes: adjust partition planning item
- b560ce7884a3 18.0 landed
-
doc PG 18 relnotes: small adjustments regarding options
- ada78f9bef2e 18.0 landed
-
doc PG 18 relnotes: move partition locking item to General Perf
- 575f6003eddb 18.0 landed
-
doc PG 18 relnotes: adjust partition items
- 45750c6cfe8d 18.0 landed
-
doc PG 18 relnotes: reword OAuth item
- c0e6aace02b6 18.0 landed
-
doc PG 18 relnotes: add mention of pg_stat_reset_backend_stats()
- 0de2e1c8b542 18.0 landed
-
doc PG 18 relnotes: adjust hash item
- 092e72a93023 18.0 landed
-
doc PG 18 relnotes: split partition optimizer item into two
- cf847d6340a6 18.0 landed
-
doc PG 18 relnotes: adjust COPY and REJECT_LIMIT items
- b3754dcc9ff7 18.0 landed
-
doc PG 18 relnotes: move and clarify constraint items
- d83981c24be7 18.0 landed
-
doc PG 18 relnotes: add commit for cancel key and protocol neg.
- 8c9eec540dc4 18.0 landed
-
doc PG 18 relnotes: fix libpq wording
- a675149e8770 18.0 landed
-
doc PG 18 relnotes: add GROUP BY column elimination item
- 24987c6f0687 18.0 landed
-
doc PG 18 relnotes: move protocol version item to "server"
- 04b269da56db 18.0 landed
-
doc PG 18 relnotes: adjust libpq trace & potocol version items
- 9f8fcadb2087 18.0 landed
-
doc PG 18 relnotes: reword and reorder items
- aa82ebdc2970 18.0 landed
-
doc: Fix memory context level in pg_log_backend_memory_contexts() example.
- 706cbed35103 18.0 cited
-
Make levels 1-based in pg_log_backend_memory_contexts()
- d9e03864b6b4 18.0 cited
-
Introduce file_copy_method setting.
- f78ca6f3ebbb 18.0 cited
-
libpq: Handle NegotiateProtocolVersion message differently
- 5070349102af 18.0 cited
-
Add timingsafe_bcmp(), for constant-time memory comparison
- 09be39112654 18.0 cited
-
Optimization for lower(), upper(), casefold() functions.
- 27bdec06841d 18.0 cited
-
Fix ALTER SUBSCRIPTION ... SET PUBLICATION ... command.
- 7c99dc587a01 18.0 cited
-
Add connection establishment duration logging
- 18cd15e706ac 18.0 cited
-
Modularize log_connections output
- 9219093cab26 18.0 cited
-
Ensure that AFTER triggers run as the instigating user.
- 01463e1cccd3 18.0 cited
-
Detect redundant GROUP BY columns using UNIQUE indexes
- bd10ec529796 18.0 cited
-
Move cancel key generation to after forking the backend
- 9d9b9d46f3c5 18.0 cited
On Sat, May 3, 2025 at 1:18 AM Bruce Momjian <bruce@momjian.us> wrote: > On Fri, May 2, 2025 at 01:00:57PM +0900, Amit Langote wrote: > > 1. Speed up execution of cached plans by deferring locks on partitions > > subject to pruning (Amit Langote) > > (bb3ec16e1, d47cbf474, cbc127917, 525392d57) > > > > 2. Speed up child EquivalenceMember lookup in planner (Yuya Watari, > > David Rowley) > > (d69d45a5a) > > > > 3. Speed up derived clause lookup in EquivalenceClass (Ashutosh Bapat) > > (88f55bc97) > > > > Alternatively, 2 and 3 can be combined as: > > > > 2. Speed up partition planning by improving EquivalenceClass lookups > > (Yuya Watari, David Rowley, Ashutosh Bapat) > > > > I think 1 should go under Partitioning, which I see is currently missing. > > > > Any thoughts, David? > > > > Can work on a patch if you'd like. > > 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. > > Also, I didn't see enough partition items to warrant a separate > partition section, and we didn't have one in PG 17 either. We could > pull all the partition items from the sections they are already in, but > they seem more natural in the sections they are in. > > I don't think most people would know what EquivalenceMember is, and even > if they did, would they be able to connect it to an SQL query? Thanks for splitting these (cf847d634). I think the text for the locking item should mention “during execution,” as David also suggested. Again, I don’t think this change belongs under Optimizer since it doesn’t really affect the planner -- it’s mainly an executor improvement. Maybe the General Performance section is a better fit. Also, just to clarify why the individual items are meaningful performance improvements: * Locking change: Executing cached plans involving hundreds or thousands of partitions was bottlenecked by locking; with this change, execution is now roughly 20x faster with 1000 partitions. * Planning time improvements: Planning certain commonly used queries against partitioned tables when they don’t use partition pruning is now roughly 20x faster with 1000 partitions. -- Thanks, Amit Langote