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
