On Thu, Apr 8, 2021 at 3:02 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Apr 7, 2021 at 12:34 PM Tom Lane <t...@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
