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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
