On Thu, Jul 13, 2023 at 8:38 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Tue, 11 Jul 2023 at 21:43, Gurjeet Singh <gurjeet@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