Re: IMMUTABLE and PARALLEL SAFE function markings - Mailing list pgsql-hackers

From Robert Haas
Subject Re: IMMUTABLE and PARALLEL SAFE function markings
Date
Msg-id CA+TgmobznkBAtvzS03Yr9f=_w9rNTAv9s4j_irmWDFtDj3woFQ@mail.gmail.com
Whole thread Raw
In response to Re: IMMUTABLE and PARALLEL SAFE function markings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: IMMUTABLE and PARALLEL SAFE function markings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Nov 26, 2018 at 11:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm.  We intentionally allow SQL functions to be marked as less mutable
> than their internals, because sometimes that's useful for tricking
> the planner.  However, IIRC we don't inline when we see that's the
> case.  Maybe there needs to be a similar restriction for parallelism
> markings.

Not sure what you have in mind here exactly.  I think that the only
correct thing to do is to mark the parent with the least safe setting
that could apply.  When you inline, you might find out that things are
safer than they initially looked, but I think by then it's too late to
change your mind because ...

> Alternatively, could we postpone the parallelism checks till after
> function inlining?  Do we even make any before that?

... I believe the parallel-safety checks are done very early, and if
you decide that it's not safe to proceed with parallelism, you can't
really change your mind later.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: IMMUTABLE and PARALLEL SAFE function markings
Next
From: Tom Lane
Date:
Subject: Re: IMMUTABLE and PARALLEL SAFE function markings