Re: Planner performance in partitions - Mailing list pgsql-performance

From MichaelDBA
Subject Re: Planner performance in partitions
Date
Msg-id 458dfc43-b097-29f3-4e0e-857b9c30b427@sqlexec.com
Whole thread Raw
In response to Re: Planner performance in partitions  (Michael Lewis <mlewis@entrata.com>)
Responses ODP: Planner performance in partitions  (Piotr Włodarczyk <piotrwlodarczyk89@gmail.com>)
List pgsql-performance
Queries against tables with a lot of partitions (> 1000) start to incur an increasing planning time duration even with the current version, V11.  V12 purportedly has fixed this problem, allowing thousands of partitioned tables without a heavy planning cost.  Can't seem to find the threads on this topic, but there are out there.  I personally noted a gigantic increase in planning time once I got past 1500 partitioned tables in V11.

On another note, hopefully they have fixed runtime partition pruning in V12 since V11 introduced it but some query plans don't use it, so you have to reconstruct some queries to sub queries to make it work correctly.

Regards,
Michael Vitale


Michael Lewis wrote on 8/12/2019 3:05 PM:
"It is also important to consider the overhead of partitioning during query planning and execution. The query planner is generally able to handle partition hierarchies with up to a few hundred partitions fairly well, provided that typical queries allow the query planner to prune all but a small number of partitions. Planning times become longer and memory consumption becomes higher as more partitions are added." (emphasis added)

pgsql-performance by date:

Previous
From: Michael Lewis
Date:
Subject: Re: Planner performance in partitions
Next
From: Piotr Włodarczyk
Date:
Subject: ODP: Planner performance in partitions