RE: Parallel INSERT SELECT take 2 - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Parallel INSERT SELECT take 2
Date
Msg-id OS0PR01MB57164107888BCC01EB42B1B894539@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Parallel INSERT SELECT take 2  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Parallel INSERT SELECT take 2
Re: Parallel INSERT SELECT take 2
List 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

Attachment

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Feedback on table expansion hook (including patch)
Next
From: Amit Langote
Date:
Subject: Re: Inherited UPDATE/DELETE vs async execution