On Thu, Jul 13, 2023 at 8:38 AM Dean Rasheed <dean.a.rash...@gmail.com> wrote: > > On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh <gurj...@singh.im> wrote:
> > { oid => '9499', descr => 'command type of current MERGE action', > > - proname => 'pg_merge_action', provolatile => 'v', > > + proname => 'pg_merge_action', provolatile => 'v', proparallel => 'r', > > .... > > { oid => '9500', descr => 'index of current MERGE WHEN clause', > > - proname => 'pg_merge_when_clause', provolatile => 'v', > > + proname => 'pg_merge_when_clause', provolatile => 'v', proparallel => > > 'r', > > .... > > > > I see that you've now set proparallel of these functions to 'r'. I'd > > just like to understand how you got to that conclusion. > > > > Now that these functions can appear in subqueries in the RETURNING > list, there exists the theoretical possibility that the subquery might > use a parallel plan (actually that can't happen today, for any query > that modifies data, but maybe someday it may become a possibility), > and it's possible to use these functions in a SELECT query inside a > PL/pgSQL function called from the RETURNING list, which might consider > a parallel plan. Since these functions rely on access to executor > state that isn't copied to parallel workers, they must be run on the > leader, hence I think PARALLEL RESTRICTED is the right level to use. A > similar example is pg_trigger_depth(). Thanks for the explanation. That helps. Best regards, Gurjeet http://Gurje.et