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 <t...@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 <alvhe...@alvh.no-ip.org> > +2018-11-16 [3f2393ede] Redesign initialization of partition routing > structures > +Author: Robert Haas <rh...@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 <t...@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 <t...@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 <br...@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 +
