Re: First draft of the PG 15 release notes

On Thu, May 19, 2022 at 2:56 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Thu, 19 May 2022 at 14:41, Amit Langote <amitlangote09(at)gmail(dot)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