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.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
