On Thu, Feb 12, 2015 at 07:40:12AM -0500, Robert Haas wrote:
> On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch <noah@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.
> 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.
Given your wish to optimize, I recommend first investigating the earlier
thought to issue eval_const_expressions() once per planner() instead of once
per subquery_planner(). Compared to the parallelModeRequired/parallelModeOK
idea, it would leave us with a more maintainable src/backend/optimizer. I
won't object to either design, though.
Your survey of parallel safety among built-in functions was on-target.
