Re: Performance of the partitioning in the large scale

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Performance of the partitioning in the large scale
Дата
Msg-id CAKJS1f-qmiGRe6ROxC-KsZh5ANeJrEyAikFzFuwtXky+cXULbw@mail.gmail.com
обсуждение исходный текст
Ответ на Performance of the partitioning in the large scale  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Ответы RE: Performance of the partitioning in the large scale  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Segfault when creating partition with a primary key and sql_droptrigger exists
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: file cloning in pg_upgrade and CREATE DATABASE