From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assessing parallel-safety |
Date: | 2015-02-13 05:10:38 |
Message-ID: | 20150213051038.GA3904350@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)leadboat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-02-13 05:27:04 | "multiple backends attempting to wait for pincount 1" |
Previous Message | Michael Paquier | 2015-02-13 04:54:03 | Strange assertion using VACOPT_FREEZE in vacuum.c |