>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Hm. We intentionally allow SQL functions to be marked as less
Tom> mutable than their internals, because sometimes that's useful for
Tom> tricking the planner. However, IIRC we don't inline when we see
Tom> that's the case. Maybe there needs to be a similar restriction for
Tom> parallelism markings.
Well, that doesn't help since not inlining the function doesn't prevent
it from being called in parallel mode.
On second thoughts the problem actually isn't directly to do with
inlining at all. The problem is that in the presence of polymorphism,
the function author can't have any confidence in setting any function as
parallel-safe, since they can't know what the actual functions are that
will be called at run time.
The _nice_ fix for this would be to make it ok to leave inlinable
functions as parallel-unsafe, and have the inlined version checked for
parallel safety. Which would require doing...
Tom> Alternatively, could we postpone the parallelism checks till after
Tom> function inlining? Do we even make any before that?
Right now, the parallelism checks are pretty much the very first thing
done on the query, right at the start of standard_planner.
--
Andrew (irc:RhodiumToad)
