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 OS0PR01MB571619395D1F7B337D2B930594549@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel INSERT SELECT take 2  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses RE: Parallel INSERT SELECT take 2  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
> > > When the parallel safety of some of these objects is changed, it's costly to
> reflect it on the parallel safety of tables that depend on them.  So, we don't do
> it.  Instead, we provide a utility function pg_get_parallel_safety('table_name')
> that returns records of (objid, classid, parallel_safety) that represent the
> parallel safety of objects that determine the parallel safety of the specified
> table.  The function only outputs objects that are not parallel safe.
> > >
> >
> > 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.

Best regards,
houzj

pgsql-hackers by date:

Previous
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Remove "FROM" in "DELETE FROM" when using tab-completion
Next
From: Dilip Kumar
Date:
Subject: Re: Small issues with CREATE TABLE COMPRESSION