public inbox for [email protected]  
help / color / mirror / Atom feed
From: Bruce Momjian <[email protected]>
To: Amit Langote <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: [email protected]
Subject: Re: PostgreSQL 12: Feature Highlights
Date: Fri, 17 May 2019 11:36:53 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAKJS1f-pCFYGq1-go+ZyAR3GisQo-nTD=7E8ykk7Zqm9w+-OkA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, May 17, 2019 at 07:56:55PM +0900, Amit Langote wrote:
> 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

Yes, it does.  I added this text and moved the commit item:

        Avoid sorting when partitions are already being scanned in the
        necessary order (David Rowley)

I certainly strugged to understand the maze of commits related to
partitioning.

> 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.

Yes.

-- 
  Bruce Momjian  <[email protected]>        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 +





view thread (63+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PostgreSQL 12: Feature Highlights
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox