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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +