Re: Performance of the partitioning in the large scale

On Thu, 27 Sep 2018 at 14:16, Kato, Sho <kato-sho@jp.fujitsu.com> wrote:
> I am planning to investigate using a system TAP etc. for other bottlenecks.
> If you have any other convenient method, please let me know.
> Also, if there is something already known as a bottleneck, please let me know.

Thanks for doing this testing.

I think instead of attempting to highlight other bottlenecks, it might
be better to focus on lending a hand reviewing and testing the
existing set of patches. It's going to be far more useful for the
people who are actually doing the performance tuning work to get some
of the work committed to allow them to move along to the next
bottleneck than to have someone highlight to them what else they
should be working on.

As for your testing. I think you should ensure that your -M prepared
tests are actually using a cached plan.  Currently, a custom plan
looks much more appealing cost wise than a generic plan with run-time
partition pruning. Unless you're running with plan_cache_mode =
'force_generic_plan' then the overhead of the partitioned cases likely
includes planning too.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services