On Wed, May 8, 2019 at 10:43:00AM +0900, Amit Langote wrote:
> I think there may be two (or more) distinct improvements here.
>
> * Performance of "pruning" itself which was bottle-necked in the planner
> is improved mostly due to:
>
> +Author: Tom Lane <tgl@sss.pgh.pa.us>
> +2019-03-30 [428b260f8] Speed up planning when partitions can be pruned at
> plan
>
> * Also improved is the performance of inserting small number of rows into
> partitioned tables which was bottle-necked in the executor because tuple
> routing would do some redundant processing per statement. The
> improvements are due to:
>
> +Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> +2018-11-16 [3f2393ede] Redesign initialization of partition routing
> structures
> +Author: Robert Haas <rhaas@postgresql.org>
> +2019-02-21 [9eefba181] Delay lock acquisition for partitions until we
> route a t
>
> * AFAICT, the following two commits don't seem to have much to do with
> improving the performance of pruning, although they are good improvements
> in their own right.
>
> +Author: Tom Lane <tgl@sss.pgh.pa.us>
> +2019-04-05 [959d00e9d] Use Append rather than MergeAppend for scanning
> ordered
>
> My summary of this optimization is that with it we can avoid paying the
> cost of merging the ordered partition outputs if partitions are determined
> to be ordered among themselves (for example, range partitions).
>
> +Author: Tom Lane <tgl@sss.pgh.pa.us>
> +2018-11-07 [c6e4133fa] Postpone calculating total_table_pages until after
> pruni
>
> My summary of this commit is that planner now correctly considers the
> effect of partition pruning on cost calculations, whereas previously it
> might end up making poor plan choices because it didn't subtract the pages
> of pruned partitions from the total_table_pages global counter.
So, in this case, there were so many partitioning improvements, I just
lumped them into one item. I think everyone can consider partitions to
perform much better in PG 12. Is there something more specific we
should communicate here?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +