On Thu, May 6, 2021 at 5:26 PM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > > Can anyone think of the need to check the parallel safety of built-in > functions in the context of parallel INSERT SELECT? The planner already > checks (or can check) the parallel safety of the SELECT part with > max_parallel_hazard(). Regarding the INSERT part, we're trying to rely on > the parallel safety of the target table that the user specified with > CREATE/ALTER TABLE. I don't see where we need to check the parallel safety > of uilt-in functions. >
Yes, I certainly can think of a reason to do this. The idea is, for the approach being discussed, is to allow the user to declare parallel-safety on a table, but then to catch any possible violations of this at runtime (as opposed to adding additional parallel-safety checks at planning time). So for INSERT with parallel SELECT for example (which runs in parallel-mode), then the execution of index expressions, column-default expressions, check constraints etc. may end up invoking functions (built-in or otherwise) that are NOT parallel-safe - so we could choose to error-out in this case when these violations are detected. As far as I can see, this checking of function parallel-safety can be done with little overhead to the current code - it already gets proc information from the system cache for non-built-in-functions, and for built-in functions it could store the parallel-safety status in FmgrBuiltin and simply get it from there (I don't think we should be allowing changes to built-in function properties - currently it is allowed, but it doesn't work properly). The other option is to just blindly trust the parallel-safety declaration on tables and whatever happens at runtime happens. Regards, Greg Nancarrow Fujitsu Australia
