On Fri, 10 May 2019 at 16:57, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > 8edd0e7 Suppress Append and MergeAppend plan nodes that have a single child.
You could say that I'm biased, but I think this should get a mention.
It's not just a matter of tidying up the plan by getting rid of nodes
that are not requires, it allows plan shapes that were not possible
before, for example, a parallel index scan on the index of a partition
and the ability to not needlessly include a Materialize node in a
Merge Join or Nested Loop Join to a partitioned table, when only 1
partition survives pruning.
I'd say wording along the lines of:
* Allow the optimizer to no longer generate plans containing a single
sub-node Append/MergeAppend node.
This allows more plan types to be considered.
[...]
> > Perform:
> > 959d00e Use Append rather than MergeAppend for scanning ordered partitions.
I also think this is worth a mention. The speedup can be quite large
when the query involves a LIMIT clause, and I think it will apply
fairly often. Most of the times I've seen partitioned table the wild
they were RANGE partitioned by a timestamp, or at least they were
inheritance based tables partitioned by timestamp that could one day
be changed to a RANGE partitioned table.
I'd say something like:
* Allow the optimizer to exploit the ordering of RANGE and LIST
partitioned tables when generating paths for partitioned tables.
This saves the optimizer from using MergeAppend node to scan a
partitioned table in order when an Append node will do.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
