Re: speeding up planning with partitions

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-01-18T05:28:32Z
Lists: pgsql-hackers
Tsunakawa-san,

On 2019/01/18 14:12, Tsunakawa, Takayuki wrote:
> From: Amit Langote [mailto:Langote_Amit_f8@lab.ntt.co.jp]
>> Are you saying that, when using auto mode, all executions of the query
>> starting from 7th are slower than the first 5 executions?  That is, the
>> latency of creating and using a custom plan increases *after* a generic
>> plan is created and discarded on the 6th execution of the query?  If so,
>> that is inexplicable to me.
> 
> Isn't CheckCachedPlan() (and AcquireExecutorLocks() therein) called in every EXECUTE after 6th one due to some unknow issue?

CheckCachedPlan is only called if choose_custom_plan() returns false
resulting in generic plan being created/reused.  With plan_cache_mode =
auto, I see it always returns true, because a custom plan containing a
single partition to scan is way cheaper than the generic plan.

> Does choose_custom_plan() always return true after 6th EXECUTE?

Yes.

Thanks,
Amit



Commits

  1. Clean up handling of constraint_exclusion and enable_partition_pruning.

  2. Add test case exercising formerly-unreached code in inheritance_planner.

  3. Speed up planning when partitions can be pruned at plan time.

  4. Avoid crash in partitionwise join planning under GEQO.

  5. Avoid passing query tlist around separately from root->processed_tlist.

  6. Build "other rels" of appendrel baserels in a separate step.

  7. Get rid of duplicate child RTE for a partitioned table.

  8. Rearrange make_partitionedrel_pruneinfo to avoid work when we can't prune.

  9. Don't copy PartitionBoundInfo in set_relation_partition_info.

  10. Move building of child base quals out into a new function

  11. Reorganize planner code moved in b60c39759908

  12. Move inheritance expansion code into its own file

  13. Fix inherited UPDATE/DELETE with UNION ALL subqueries.

  14. Rearrange planner to save the whole PlannerInfo (subroot) for a subquery.