Re: Parallel INSERT (INTO ... SELECT ...)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Parallel INSERT (INTO ... SELECT ...)
Дата
Msg-id CAA4eK1JEn9dVphLKfY0Noj4ZfNCveuEPeYwD+KnWPiZSVWQNjw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Ответы RE: Parallel INSERT (INTO ... SELECT ...)  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Список pgsql-hackers
On Thu, Jan 14, 2021 at 2:37 PM Tang, Haiying
<tanghy.fnst@cn.fujitsu.com> wrote:
>
> Hi Greg, Amit
> Cc:hackers
>
> > > > 4. Have you checked the overhead of this on the planner for
> > > > different kinds of statements like inserts into tables having 100
> > > > or 500 partitions? Similarly, it is good to check the overhead of
> > > > domain related checks added in the patch.
> > > >
> > >
> > > Checking that now and will post results soon.
> > >
> >I am seeing a fair bit of overhead in the planning for the INSERT
> >parallel-safety checks (mind you, compared to the overall performance
> >gain, it's not too bad).
>
> Considering the 'real-world' use cases and extreme cases I can imagine, I took 3 kinds of measurements on partition
tablefor the latest patch(V11).
 
> The measurement is mainly focus on small rows because this could be easier to evaluate check overhead among the
parallelismoptimization.
 
> From current results, the overhead looks acceptable compared to the benefits as Greg said.
>

Can we test cases when we have few rows in the Select table (say 1000)
and there 500 or 1000 partitions. In that case, we won't select
parallelism but we have to pay the price of checking parallel-safety
of all partitions. Can you check this with 100, 200, 500, 1000
partitions table?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: japin
Дата:
Сообщение: Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION
Следующее
От: vignesh C
Дата:
Сообщение: Re: Added schema level support for publication.