On Sat, Mar 13, 2021 at 10:08 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Greg Nancarrow <gregn4...@gmail.com> writes: > > On Fri, Mar 12, 2021 at 5:00 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> BTW, having special logic for FK triggers in > >> target_rel_trigger_max_parallel_hazard seems quite loony to me. > >> Why isn't that handled by setting appropriate proparallel values > >> for those trigger functions? > > > ... and also attached a patch to update the code for this issue. > > Hm, what I was expecting to see is that RI_FKey_check_ins and > RI_FKey_check_upd get marked as proparallel = 'r' and the remainder > get marked as proparallel = 'u'. >
oh, I think Greg's patch has just marked functions for which the current code has parallel-safety checks and I also thought that would be sufficient. > Remember that the default for > builtin functions is proparallel = 's', but surely that's wrong > for triggers that can propagate updates to other tables? > Okay, probably the others can be marked as unsafe. I think we have not considered others except for FK-related triggers which we knew are hazardous for enabling inserts in parallel-mode. The others seem to be related to update/delete, so we have not done anything, but maybe it is better to mark them as 'unsafe' now, and later when we support the update/delete in parallel-mode, we can see if any of those can be executed in parallel-mode. But OTOH, we can keep them as it is if they don't impact the current operation we have supported in parallel-mode. -- With Regards, Amit Kapila.
