Re: assessing parallel-safety

On Sat, Feb 07, 2015 at 08:18:55PM -0500, Robert Haas wrote:
> There are a few problems with this design that I don't immediately
> know how to solve:
>
> 1. I'm concerned that the query-rewrite step could substitute a query
> that is not parallel-safe for one that is. The upper Query might
> still be flagged as safe, and that's all that planner() looks at.

I would look at determining the query's parallel safety early in the planner
instead; simplify_function() might be a cheap place to check. Besides
avoiding rewriter trouble, this allows one to alter parallel safety of a
function without invalidating Query nodes serialized in the system catalogs.

> 2. Interleaving the execution of two parallel queries by firing up two
> copies of the executor simultaneously can result in leaving parallel
> mode at the wrong time.

Perhaps the parallel mode state should be a reference count, not a boolean.
Alternately, as a first cut, just don't attempt parallelism when we're already
in parallel mode.

> 3. Any code using SPI has to think hard about whether to pass
> OPT_CURSOR_NO_PARALLEL. For example, PL/pgsql doesn't need to pass
> this flag when caching a plan for a query that will be run to
> completion each time it's executed. But it DOES need to pass the flag
> for a FOR loop over an SQL statement, because the code inside the FOR
> loop might do parallel-unsafe things while the query is suspended.

That makes sense; the code entering SPI knows best which restrictions it can
tolerate for the life of a given cursor. (One can imagine finer-grained rules
in the future. If the current function is itself marked parallel-safe, it's
safe in principle for a FOR-loop SQL statement to use parallelism.) I do
recommend inverting the sense of the flag, so unmodified non-core PLs will
continue to behave as they do today.

Thanks,
nm