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>
 <3ea29ec1-38e9-b5bd-571e-8d1f85175c5a@lab.ntt.co.jp>
 <CAKJS1f84HJj3qiDzpX9-iz_6AAdiX7khtgUf0UPVEmEd3YZ4hQ@mail.gmail.com>
 <20190514025918.mqfedp3k625t5eoc@momjian.us>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <b7954643-41ef-a174-479d-1f8d4834f40a@lab.ntt.co.jp>
Date: Tue, 14 May 2019 18:25:43 +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: <20190514025918.mqfedp3k625t5eoc@momjian.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
To: Bruce Momjian <bruce@momjian.us>,
        David Rowley <david.rowley@2ndquadrant.com>
Cc: Justin Clift <justin@postgresql.org>,
        "Jonathan S. Katz" <jkatz@postgresql.org>,
        pgsql-advocacy@lists.postgresql.org
Precedence: bulk

On 2019/05/14 11:59, Bruce Momjian wrote:
> On Mon, May 13, 2019 at 10:50:59PM +1200, David Rowley wrote:
>> On Mon, 13 May 2019 at 18:37, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> 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.
>>
>> This is true, but whether partitions are pruned or not is only
>> relevant to one of the many items the headline feature is talking
>> about. I'm not sure how you'd briefly enough mention that fact without
>> going into detail about which features are which and which are
>> affected by partition pruning.
>>
>> I think these are the sorts of details that can be mentioned away from
>> the headline features, which is why I think lumping these all in one
>> in the main release notes is a bad idea as it's pretty hard to do that
>> when they're all lumped in as one item.
> 
> I think the point is that partition pruning and tuple _routing_ to the
> right partition is also improved.  I updated the release note items to
> say:
> 
> 	Tables with thousands of child partitions can now be processed
> 	efficiently.

Considering the quoted discussion here, maybe it's a good idea to note
that only the operations that need to touch a small number of partitions
are now processed efficiently, which covers both SELECT/UPDATE/DELETE that
benefit from improved pruning efficiency and INSERT that benefit from
improved tuple routing efficiency.  So, maybe:

	Tables with thousands of child partitions can now be processed
	efficiently by operations that only need to touch a small number
        of partitions.

That is, as I mentioned above, as opposed to queries that need to process
all partitions (such as, select count(*) from partitioned_table), which
don't perform any faster in v12 than in v11.  The percentage of users who
run such workloads on PostgreSQL may be much smaller today, but perhaps
it's not a good idea to mislead them into thinking that *everything* with
partitioned tables is now faster even with thousands of partitions.

Thanks,
Amit