Re: Parallel INSERT SELECT take 2

On Mon, May 10, 2021 at 11:21 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> Now, in the declarative approach, we can either go with whatever the
> user has mentioned or we can do some checks during DDL to determine
> the actual parallel-safety. I think even if try to determine
> parallel-safety during DDL it will be quite tricky in some cases, like
> when a user performs Alter Function to change parallel-safety of the
> function used in some constraint for the table or if the user changes
> parallel-safety of one of the partition then we need to traverse the
> partition hierarchy upwards which doesn't seem advisable. So, I guess
> it is better to go with whatever the user has mentioned but if you or
> others feel we can have some sort of parallel-safety checks during DDL
> as well.

IMHO, it makes sense to go with what the user has declared to avoid
complexity. And, I don't see any problem with that.

> > The planner assumes that all of the table, its descendant partitions, and their ancillary objects have the specified parallel safety or safer one. The user is responsible for its correctness. If the parallel processes find an object that is less safer than the assumed parallel safety during statement execution, it throws an ERROR and abort the statement execution.
> >
> > The objects that relate to the parallel safety of a DML target table are as follows:
> >
> > * Column default expression
> > * DOMAIN type CHECK expression
> > * CHECK constraints on column
> > * Partition key
> > * Partition key support function
> > * Index expression
> > * Index predicate
> > * Index AM function
> > * Operator function
> > * Trigger function
> >
> > 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.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com