From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Justin Clift <justin(at)postgresql(dot)org> |
Cc: | "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-13 06:37:05 |
Message-ID: | 3ea29ec1-38e9-b5bd-571e-8d1f85175c5a@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
Hi David,
On 2019/05/13 11:19, David Rowley wrote:
> On Mon, 13 May 2019 at 13:50, Justin Clift <justin(at)postgresql(dot)org> wrote:
>>
>> On 2019-05-13 09:47, David Rowley wrote:
>>> On Mon, 13 May 2019 at 03:28, Jonathan S. Katz <jkatz(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2019-05-13 09:14:48 | Re: PostgreSQL 12: Feature Highlights |
Previous Message | David Rowley | 2019-05-13 02:19:45 | Re: PostgreSQL 12: Feature Highlights |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-05-13 06:38:23 | Re: SQL-spec incompatibilities in similar_escape() and related stuff |
Previous Message | David Fetter | 2019-05-13 05:51:12 | Re: New EXPLAIN option: ALL |