On Sat, May 14, 2022 at 12:42 AM Bruce Momjian <br...@momjian.us> wrote: > On Fri, May 13, 2022 at 10:48:41AM +0900, Amit Langote wrote: > > Btw, perhaps the following should be listed under E.1.3.2.1. Logical > > Replication, not E.1.3.1.1. Partitioning? > > > > <!-- > > Author: Amit Kapila <akap...@postgresql.org> > > 2021-12-08 [a61bff2bf] De-duplicate the result of pg_publication_tables > > view. > > --> > > > > <listitem> > > <para> > > Remove incorrect duplicate partitions in system view > > pg_publication_tables (Hou Zhijie) > > </para> > > </listitem> > > > > Attached a patch to do so. > > Agreed, done.
Thank you. 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 the "Now only non-pruned LIST partitions are checked" bit in the original wording is really an implementation detail of the actual improvement that ordered partition scans are now possible in more cases -- it simply became easier for the code that implements this optimization to refer to non-pruned partitions, using a bitmapset rather than having to trawl through the whole array of partition rels, which is what I think the commit message of this item mentions. David can correct me if I got that wrong. Attached a patch. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com
reword-ordered-partition-scan-item.diff
Description: Binary data
