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

From Bharath Rupireddy
Subject Re: Parallel INSERT SELECT take 2
Date
Msg-id CALj2ACWXQMS_1vdjeMBXO819HjqHn=g8M7A8cXhUJ4tknumwqw@mail.gmail.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  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Tue, May 11, 2021 at 6:11 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> > > > 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.

Thanks for the patches. I think we should have the table name as
regclass type for pg_get_max_parallel_hazard? See, pg_relation_size,
pg_table_size, pg_filenode_relation and so on.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Python 3.10 breaks regression tests with traceback changes
Next
From: Joe Conway
Date:
Subject: Re: PG 14 release notes, first draft