Re: assessing parallel-safety

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.

In response to

Responses

Browse pgsql-hackers by date

  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