On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch <n...@leadboat.com> wrote: > That is a major mark against putting the check in simplify_function(), agreed.
I do see one way to rescue that idea, which is this: put two flags, parallelModeOK and parallelModeRequired, into PlannerGlobal. At the beginning of planning, set parallelModeOK based on our best knowledge at that time; as we preprocess expressions, update it to false if we see something that's not parallel-safe. Emit paths for parallel plans only if the flag is currently true. At the end of planning, when we convert paths to plans, set parallelModeRequired if any parallel plan elements are generated. If we started with parallelModeOK = true or ended up with parallelModeRequired = false, then life is good. In the unfortunate event that we end up with parallelModeOK = false and parallelModeRequired = true, replan, this time with parallelModeOK = false from the beginning. If there are no sub-queries involved, this will work out fine - parallelModeOK will always be definitively set to the right value before we rely on it for anything. This includes cases where subqueries are eliminated by pulling them up. If there *are* subqueries, we'll still be OK if we happen to hit the parallel-unsafe construct before we hit the part - if any - that can benefit from parallelism. So this would mostly be pretty cheap, but if you do hit the case where a re-plan is required it would be pretty painful. >> > 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. > > I expect that would work fine, but I do think it premature to venture that far > out of your way to optimize this new tree examination. The cost may just not > matter. Other parts of the planner use code like contain_volatile_functions() > and contain_nonstrict_functions(), which have the same kind of inefficiency > you're looking to avoid here. They do, but those are run on much smaller pieces of the query tree, never on the whole thing. I really wish Tom Lane would weigh in here, as an opinion from him could save me from spending time on a doomed approach. I expect criticism of this type: http://www.postgresql.org/message-id/22266.1269641...@sss.pgh.pa.us -- 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
