On Sun, Feb 8, 2015 at 12:28 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Feb 8, 2015 at 11:31 AM, Noah Misch <n...@leadboat.com> wrote: >> 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. > > Thanks, I'll investigate that approach.
This does not seem to work out nicely. The problem here is that simplify_function() gets called from eval_const_expressions() which gets called from a variety of places, but the principal one seems to be subquery_planner(). So if you have a query with two subqueries, and the second one contains something parallel-unsafe, you might by that time have already generated a parallel plan for the first one, which won't do. Unless we want to rejigger this so that we do a complete eval_const_expressions() pass over the entire query tree (including all subqueries) FIRST, and then only after that go back and plan all of those subqueries, I don't see how to make this work; and I'm guessing that there are good reasons not to do that. Ideas? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
