Re: PostgreSQL 12: Feature Highlights
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: David Rowley <david.rowley@2ndquadrant.com>,
Justin Clift <justin@postgresql.org>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
pgsql-advocacy@lists.postgresql.org
Date: 2019-05-13T06:37:05Z
Lists: pgsql-hackers
Hi David, On 2019/05/13 11:19, David Rowley wrote: > On Mon, 13 May 2019 at 13:50, Justin Clift <justin@postgresql.org> wrote: >> >> On 2019-05-13 09:47, David Rowley wrote: >>> On Mon, 13 May 2019 at 03:28, Jonathan S. Katz <jkatz@postgresql.org> >>> wrote: >>>> - Performance, e.g. enhanced partition pruning, COPY performance, >>>> ATTACH >>> >>> I don't think it's very accurate to say that the performance of >>> partition pruning has been improved. Really the improvement there is >>> due to the change in the order of operations, where we now perform >>> pruning before fetching partition meta-data. Pruning itself, I don't >>> believe became any faster in PG12. There were, however various tweaks >>> to improve performance of some operations around run-time partition >>> pruning both in the planner and during execution, these, however, are >>> not improvements to pruning itself, but more the operations around >>> setting up pruning and handling what happens after pruning takes >>> place. Bruce has now changed the release notes to mention "Improve >>> performance of many operations on partitioned tables", which seems >>> like a more accurate generalisation of what was improved, although, I >>> still think it's overly vague. >> >> Sounds like "partition pruning is now more efficient". eg less memory >> usage (?), with a side effect of better performance leading from that >> (?) > > I think the headline item needs to be about the fact that partitioning > can now more easily handle larger numbers of partitions. To say > pruning is more efficient is just a chapter in the story. The big > users of partitioning want and need the entire book. > > Perhaps something along the lines of: > > - Improve optimizer and executor to allow them to more easily handle > larger numbers of partitions. It's true that optimizer and executor can now handle larger number of partitions efficiently, but the improvements in this release will only be meaningful to workloads where partition pruning is crucial, so I don't see why mentioning "pruning" is so misleading. Perhaps, it would be slightly misleading to not mention it, because readers might think that queries like this one: select count(*) from partitioned_table; are now faster in v12, whereas AFAIK, they perform perform more or less the same as in v11. Thanks, Amit
Commits
-
doc: PG 12 relnotes, add mention of single-child optimization
- b9a0724cf7a3 12.0 landed
-
docs: split out sort-skip partition item in PG 12 release notes
- 05685897f07e 12.0 landed
-
docs: update partition item in PG 12 release notes
- 356c83795aaa 12.0 landed