MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 13 May 2019 11:50:00 +1000
From: Justin Clift <justin@postgresql.org>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
 pgsql-advocacy@lists.postgresql.org
Subject: Re: PostgreSQL 12: Feature Highlights
In-Reply-To: 
 <CAKJS1f-1=BoVkJaTnfb87nrVUFLprdc7smsBsF5MGyCXnNivzw@mail.gmail.com>
References: <830415f7-78ec-ef7b-0f73-0e810ef87f91@postgresql.org>
 <CAKJS1f-1=BoVkJaTnfb87nrVUFLprdc7smsBsF5MGyCXnNivzw@mail.gmail.com>
Message-ID: <f03b23b1226802f099e62ec444f9dfdc@postgresql.org>
User-Agent: Roundcube Webmail/1.2.3
Precedence: bulk

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 
(?)