RE: Parallel INSERT SELECT take 2

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: Parallel INSERT SELECT take 2
Дата
Msg-id OS0PR01MB57164107888BCC01EB42B1B894539@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Parallel INSERT SELECT take 2  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Ответы Re: Parallel INSERT SELECT take 2  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: Parallel INSERT SELECT take 2  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
> > > So, users need to check count(*) for this to determine
> > > parallel-safety? How about if we provide a wrapper function on top
> > > of this function or a separate function that returns char to
> > > indicate whether it is safe, unsafe, or restricted to perform a DML
> > > operation on the table?
> >
> > Such wrapper function make sense.
> 
> Thanks for the suggestion, and I agree.
> I will add another wrapper function and post new version patches soon.

Attaching new version patches with the following changes:

0001
Add a new function pg_get_max_parallel_hazard('table_name') returns char('s', 'u', 'r')
which indicate whether it is safe, unsafe, or restricted to perform a DML.

0003
Temporarily, I removed the safety check for function in the executor.
Because we are trying to post the safety check as a separate patch which
can help detect parallel unsafe function in parallel mode, and the approach
is still in discussion[1].
Comments and suggestions are welcome either in that thread[1] or here.

[1]
https://www.postgresql.org/message-id/OS0PR01MB571646637784DAF1DD4C8BE994539%40OS0PR01MB5716.jpnprd01.prod.outlook.com

Best regards,
houzj

Вложения

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

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Feedback on table expansion hook (including patch)
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Inherited UPDATE/DELETE vs async execution