From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | RE: Parallel INSERT SELECT take 2 |
Date: | 2021-05-11 12:40:53 |
Message-ID: | OS0PR01MB57164107888BCC01EB42B1B894539@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
Best regards,
houzj
Attachment | Content-Type | Size |
---|---|---|
v3-POC-0003-xid-related-and-testcase.patch | application/octet-stream | 37.1 KB |
v3-POC-0001-get-parallel-safety-functions.patch | application/octet-stream | 31.5 KB |
v3-POC-0002-CREATE-ALTER-TABLE-PARALLEL-DML.patch | application/octet-stream | 39.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-05-11 12:53:24 | Re: Inherited UPDATE/DELETE vs async execution |
Previous Message | Aleksander Alekseev | 2021-05-11 12:29:45 | Re: Feedback on table expansion hook (including patch) |