Re: pgsql: docs: fist draft version of the PG 12 release notes

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(at)sss(dot)pgh(dot)pa(dot)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(at)alvh(dot)no-ip(dot)org>
> +2018-11-16 [3f2393ede] Redesign initialization of partition routing
> structures
> +Author: Robert Haas <rhaas(at)postgresql(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)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 +