Re: How to make partitioning scale better for larger numbers of partitions

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: How to make partitioning scale better for larger numbers of partitions
Дата
Msg-id CAFjFpRcMCtg+Upxui=0SjnGqPX5Fxb1upmXV374S-yMoSn=0hA@mail.gmail.com
обсуждение исходный текст
Ответ на RE: How to make partitioning scale better for larger numbers ofpartitions  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Ответы Re: How to make partitioning scale better for larger numbers ofpartitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Jul 17, 2018 at 8:31 AM, Kato, Sho <kato-sho@jp.fujitsu.com> wrote:
> On 2018/07/17 10:49, Amit Langote wrote:
>>Perhaps, Kato-san only intended to report that the time that planner spends for a partitioned table with 1100
partitionsis just too high compared to the time it spends on a non-partitioned table.
 
>
> yes, It is included for the purposes of this comparison.
>
> The purpose of this comparison is to find where the partitioning bottleneck is.
> Using the bottleneck as a hint of improvement, I'd like to bring the performance of partitioned table closer to the
performanceof unpartitioned table as much as possible.
 
>

That's a good thing, but may not turn out to be realistic. We should
compare performance where partitioning matters and try to improve in
those contexts. Else we might improve performance in scenarios which
are never used.

In this case, even if we improve the planning time by 100%, it hardly
matters since planning time is neglegible compared to the execution
time because of huge data where partitioning is useful.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Kato, Sho"
Дата:
Сообщение: RE: How to make partitioning scale better for larger numbers ofpartitions
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Let's remove DSM_IMPL_NONE.