On Sun, 19 May 2019 at 01:20, Bruce Momjian <bruce@momjian.us> wrote:
> The first one needs to reference visible effects, so I would add:
>
> Consider additional optimizations for queries referencing
> partitioned tables that only affect a single partition
>
> Does that work?
Thanks, typing that up. I think it lacks a bit detail about what's
actually changed. The change is fairly evident and people can see
when it takes effect when they look at EXPLAIN and see that the
Append/MergeAppend node is missing. Also, an Append/MergeAppend may
exist for inheritance tables and an Append can exist for a simple
UNION ALL. Both of those cases can have subplans removed to leave only
a single subplan, to which the additional parallel paths will be
considered.
I think something like:
* Make the optimizer only include an Append/MergeAppend node when
there is more than one subplan to append.
This reduces execution overheads and allows additional plan shapes
that were previously not possible.
or a little more brief:
* Allow the optimizer to consider more plan types by eliminating
single subplan Append and MergeAppends.
I understand that you might be trying to avoid details of plan node
types, but really anyone who's got inheritance or partitioned tables
and has looked at an EXPLAIN should have an idea.
Also, I think Tom should be the main author of this as he rewrote my
version of the patch to such an extent that there was next to nothing
of it left. I just tagged a few extra things on before he committed
it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services