Re: Planning time of Generic plan for a table partitioned into a lot

On Fri, 30 Nov 2018 at 20:15, Kato, Sho <kato-sho@jp.fujitsu.com> wrote:
> Will we improve creating the generic plan in the future?

I think Amit's patch will improve the UPDATE/DELETE planning
performance even when nothing can be pruned.  Currently planning those
are quite inefficient as a separate grouping planner call is made for
each partition.

> For example, if there is UPDATE / DELETE run-time partition pruning, creating the generic plan will also be faster.

Adding run-time pruning code for that won't make the planner any
faster. There will be a very slight overhead to build the required
PartitionPruneInfo struct to attach to the plan in order to allow the
run-time pruning to work. This would mean that there'd only be a hope
of reducing the execution time of such a plan, not the time to build
the plan in the first place.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services