On Mon, May 10, 2021 at 11:21 AM Amit Kapila <amit.kapil...@gmail.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
