Re: First draft of the PG 15 release notes

Amit Langote <amitlangote09@gmail.com>

From: Amit Langote <amitlangote09@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-05-19T09:13:28Z
Lists: pgsql-hackers

Attachments

On Thu, May 19, 2022 at 2:56 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Thu, 19 May 2022 at 14:41, Amit Langote <amitlangote09@gmail.com> wrote:
> > Though a bit late given beta is now wrapped, I have another partition
> > item wording improvement suggestion:
> >
> > -Previously, a partitioned table with any LIST partition containing
> > multiple values could not be used for ordered partition scans.  Now
> > only non-pruned LIST partitions are checked.  This also helps with
> > -partitioned tables with DEFAULT partitions.
> >
> > +Previously, an ordered partition scan would not be considered for a
> > LIST-partitioned table with any partition containing multiple values,
> > nor for partitioned tables with DEFAULT partition.
>
> I think your proposed wording does not really improve things.  The
> "Now only non-pruned LIST partitions are checked" is important and I
> think Bruce did the right thing to mention that. Prior to this change,
> ordered scans were not possible if there was a DEFAULT or if any LIST
> partition allowed >1 value. Now, if the default partition is pruned
> and there are no non-pruned partitions that allow Datum values that
> are inter-mixed with ones from another non-pruned partition, then an
> ordered scan can be performed.
>
> For example, non-pruned partition a allows IN(1,3), and non-pruned
> partition b allows IN(2,4), we cannot do the ordered scan. With
> IN(1,2), IN(3,4), we can.

I think that's what I understood this change to be about.  Before this
change, partitions_are_ordered() only returned true if *all*
partitions of a parent are known to be ordered, which they're not in
the presence of the default partition and of a list partition
containing out-of-order values.  It didn't matter to
partitions_are_ordered() that the caller might not care about those
partitions being present in the PartitionDesc because of having been
pruned by the query, but that information was not readily available .
So, you added PartitionBoundInfo.interleaved_parts to record indexes
of partitions containing out-of-order values and RelOptInfo.live_parts
to record non-pruned partitions, which made it more feasible for
partitions_are_ordered() to address those cases.  I suppose you think
it's better to be verbose by mentioning that partitions_are_ordered()
now considers only non-pruned partitions which allows supporting more
cases, but I see that as mentioning implementation details
unnecessarily.

Or maybe we could mention that but use a wording that doesn't make it
sound like an implementation detail, like:

+Previously, an ordered partition scan could not be used for a
LIST-partitioned table with any partition containing multiple values,
nor for partitioned tables with DEFAULT partition.  Now it can be used
in those cases at least for queries in which such partitions are
pruned.


--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

Commits

  1. Doc: last minute adjustment to the release notes

  2. Doc: more tweaking of v15 release notes.

  3. Doc: further adjust notes about pg_upgrade_output.d.

  4. Doc: add list of major features to the v15 release notes.

  5. relnotes: update item about public schema permission change

  6. relnotes: update ordered partition scan item

  7. relnotes: add Heikki to UTF8 item

  8. relnotes: improve UTF8 text item in relation to ASCII

  9. relnotes: add null logical replication item

  10. relnotes: adjust several logical replication items and FK text

  11. relnotes: mention non-exclusive backup mode was deprecated

  12. relnotes: add author to in-memory sorts item

  13. relnotes: update for non-exclusive backup mode removal

  14. relnote: improve sorting entries

  15. relnotes: adjustments from Álvaro Herrera

  16. relnotes: update foreign key partition and add sort items

  17. relnotes: more adjustments

  18. relnotes: logical replication permissions checked by subscrib.

  19. relnotes: adjustments

  20. relnotes: remove sequence replication and update 'postgres -C'

  21. relnote: extensive updates

  22. relnotes: "training" -> "trailing"

  23. Standardize references to Zstandard as <productname>

  24. pgstat: Update docs to match the shared memory stats reality.

  25. Raise a WARNING for missing publications.

  26. Skip empty transactions for logical replication.

  27. Optionally disable subscriptions on error.

  28. Allow root-owned SSL private keys in libpq, not only the backend.

  29. Use COPY FREEZE in pgbench for faster benchmark table population.