Re: Performance of the partitioning in the large scale - Mailing list pgsql-hackers

From David Rowley
Subject Re: Performance of the partitioning in the large scale
Date
Msg-id CAKJS1f-qmiGRe6ROxC-KsZh5ANeJrEyAikFzFuwtXky+cXULbw@mail.gmail.com
Whole thread Raw
In response to Performance of the partitioning in the large scale  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Responses RE: Performance of the partitioning in the large scale  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Segfault when creating partition with a primary key and sql_droptrigger exists
Next
From: Peter Eisentraut
Date:
Subject: Re: file cloning in pg_upgrade and CREATE DATABASE