Subject: Re: PostgreSQL 12: Feature Highlights
References: <830415f7-78ec-ef7b-0f73-0e810ef87f91@postgresql.org>
 <CAKJS1f-1=BoVkJaTnfb87nrVUFLprdc7smsBsF5MGyCXnNivzw@mail.gmail.com>
 <f03b23b1226802f099e62ec444f9dfdc@postgresql.org>
 <CAKJS1f9=xUz5y=VDy6hYMVpSoej9+D2BminegmfqHwdWQfpQ9w@mail.gmail.com>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <3ea29ec1-38e9-b5bd-571e-8d1f85175c5a@lab.ntt.co.jp>
Date: Mon, 13 May 2019 15:37:05 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
 <CAKJS1f9=xUz5y=VDy6hYMVpSoej9+D2BminegmfqHwdWQfpQ9w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
To: David Rowley <david.rowley@2ndquadrant.com>,
        Justin Clift <justin@postgresql.org>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
        pgsql-advocacy@lists.postgresql.org
Precedence: bulk

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