On Thu, Apr 8, 2021 at 3:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Apr 7, 2021 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Indeed, that's a pretty impressive comparison.
>
> > +1. That looks like a big improvement.
>
> > In a vacuum, you'd hope that partitioning a table would make things
> > faster rather than slower, when only one partition is implicated. Or
> > at least that the speed would stay about the same. And, while this is
> > a lot better, we're clearly not there yet. So I hope that, in future
> > releases, we can continue to find ways to whittle down the overhead.
>
> Note that this test case includes plan_cache_mode = force_generic_plan,
> so it's deliberately kneecapping our ability to tell that "only one
> partition is implicated".
For the record, here are the numbers for plan_cache_mode = auto.
(Actually, plancache.c always goes with custom planning for
partitioned tables.)
v13.2
nparts 10cols 20cols 40cols
64 13391 12140 10958
128 13436 12297 10643
256 12564 12294 10355
1024 11450 10600 9020
v14dev HEAD
64 14925 14648 13361
128 14379 14333 13138
256 14478 14246 13316
1024 12744 12621 11579
There's 10-20% improvement in this case too for various partition
counts, which really has more to do with 86dc90056 than the work done
here.
--
Amit Langote
EDB: http://www.enterprisedb.com
