Re: PostgreSQL 12: Feature Highlights

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, pgsql-advocacy(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL 12: Feature Highlights
Date: 2019-05-17 10:56:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-advocacy pgsql-hackers

On 2019/05/17 3:26, Bruce Momjian wrote:
> I think the more specific we make the partition description, the more
> limited it will appear to be. I think almost all partition operations
> will appear to be faster with PG 12, even if users can't articulate
> exactly why.

I agree that the current description captures at a high level the many
changes that made it possible. Although, a couple of commits listed with
this item don't have much to do with that description, AFAICT. Especially
959d00e9d [1], which taught the planner to leverage the ordering imposed
on partitions by range partitioning. With that commit, getting ordered
output from partitioned tables is now much quicker, especially with a
LIMIT clause. You can tell that it sounds clearly unrelated to the
description we have now, which is "processing thousands of partitions is
quicker when only small numbers of partitions are touched". Some users of
partitioning may not be interested in the use case described as vastly
improved, but they may be delighted to hear about items such as the
aforementioned commit. Also, I suspect that the users whose use cases
pushed them to use partitioning in the first place may also be the ones
who do some of their own research about partitioning and eventually know
many optimizations that are possible with it. So, it's perhaps a good
idea to let them know about such optimizations through release notes if
it's the only place to put them, which I believe is the case with this
particular item. There are not that many commits to be taken out of the
existing item and described separately, just this one I think.

That said, my intention is only to point out that the commit is being
mixed with an unrelated item. Whether or not to list it as a separate
item, I can only give my vote in its favor.


[1] [959d00e9d] Use Append rather than MergeAppend for scanning ordered

In response to


Browse pgsql-advocacy by date

  From Date Subject
Next Message Evan Macbeth 2019-05-17 12:14:33 Re: PostgreSQL 12: Feature Highlights
Previous Message Michael Paquier 2019-05-17 03:50:12 Re: PostgreSQL 12: Feature Highlights

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2019-05-17 10:59:58 Re: pglz performance
Previous Message Lætitia Avrot 2019-05-17 10:28:20 Re: [Doc] pg_restore documentation didn't explain how to use connection string