Re: PostgreSQL 12: Feature Highlights
От | David Rowley |
---|---|
Тема | Re: PostgreSQL 12: Feature Highlights |
Дата | |
Msg-id | CAKJS1f-pCFYGq1-go+ZyAR3GisQo-nTD=7E8ykk7Zqm9w+-OkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL 12: Feature Highlights (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: PostgreSQL 12: Feature Highlights
|
Список | pgsql-advocacy |
On Wed, 15 May 2019 at 14:31, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > > On 2019/05/15 11:03, Jonathan S. Katz wrote: > > 2. Partitioning Improvements > > > > - Improved partition pruning, which improves performance on queries over > > tables with thousands of partitions that only need to use a few partitions > > - Improvements to COPY performance and ATTACH PARTITION > > - Allow foreign keys to reference partitioned tables > > About the 1st item in "Partitioning Improvements", it's not just partition > pruning that's gotten better. How about writing as: > > - Improved performance of processing tables with thousands of partitions > for operations that only need to touch a small number of partitions > > Per discussion upthread, that covers improvements to both partition > pruning and tuple routing. +1. Amit's words look fine to me. I think if we're including this as a headline feature then it should be to inform people that partitioning is generally more useable with larger numbers of partitions, not just that SELECT/UPDATE/DELETE now perform better when pruning many partitions. The work done there and what's done to speed up tuple routing in INSERT/COPY both complement each other, so they're likely good to keep as one in the headline features list. Mentioning one without the other might leave some people guessing about if we've addressed the other deficiencies with partitioning performance. Sadly, they can't refer to the release notes for more information since they don't detail what's changed in this area :( -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-advocacy по дате отправления: