>>>>> "Tom" == Tom Lane <t...@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)
