RE: Determine parallel-safety of partition relations for Inserts

Поиск
Список
Период
Сортировка
От Hou, Zhijie
Тема RE: Determine parallel-safety of partition relations for Inserts
Дата
Msg-id 09b79792101548a3a83e8e57722b3f74@G08CNEXMBPEKD05.g08.fujitsu.local
обсуждение исходный текст
Ответ на Re: Determine parallel-safety of partition relations for Inserts  (Greg Nancarrow <gregn4422@gmail.com>)
Ответы Re: Determine parallel-safety of partition relations for Inserts  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
Hi greg,

Thanks for the review !

> Personally, I think a table's "parallel_dml" option should be ON by default.
> It's annoying to have to separately enable it for each and every table being
> used, when I think the need to turn it selectively OFF should be fairly
> rare.

Yes, I agreed.
Changed.

> And I'm not sure that "parallel_dml" is the best name for the table option
> - because it sort of implies parallel dml WILL be used - but that isn't
> true, it depends on other factors too.
> So I think (to be consistent with other table option naming) it would have
> to be something like "parallel_dml_enabled".

Agreed.
Changed to parallel_dml_enabled.

Attatching v2 patch which addressed the comments above.

Some further refactor:

Introducing a new function is_parallel_possible_for_modify() which decide whether to do safety check.

IMO, It seems more readable to extract all the check that we can do before the safety-check and put them
in the new function.

Please consider it for further review.

Best regards,
houzj



Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Single transaction in the tablesync worker?
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Add extra statistics to explain for Nested Loop