On Wed, May 25, 2022 at 8:36 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Thu, May 19, 2022 at 06:13:28PM +0900, Amit Langote wrote:
> > 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.
>
> Sorry, I just don't see this as an improvement because it starts with a
> complex term "an ordered partition scan" rather than simply "a
> partitioned table".
The headline says "Allow ordered scans of partitions to avoid sorting
in more cases", so I proposed starting the description too with "an
ordered scan". Also, not sure about going with:
"previously, <table-with-limiting-properties> could not be used for
<scan-method>, but now it can be provided <conditions>"
instead of:
"previously, <scan-method> could not be used for
<table-with-limiting-properties>, but now it can be provided
<conditions>"
as in my proposed wording, but maybe that's just me.
Anyway, I still think it would be better to fix the description such
that the cases in which ordered scans will continue to not be usable
are clear. The existing text doesn't make clear, for example, that a
DEFAULT partition if present must have been pruned for an ordered scan
to be used. So I propose:
+Previously, a partitioned table with DEFAULT partition or a LIST
partition containing multiple values could not be used for ordered
partition scans. Now it can be used at least in the cases where such
partitions are pruned.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com