From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql: Simplify plpgsql's check for simple
 expressions.
In-reply-to: 
 <CA+TgmoYB4EfN4FkpWf3UFRgMgrA2Go7FgFmu-p7Yzh+WDx9E5A@mail.gmail.com>
References: <E1dhehy-00034e-8N@gemulon.postgresql.org>
 <23425.1502822098@sss.pgh.pa.us>
 <CA+TgmoaRuLrYSonO5y4-Dhiaw13yTukKWyJuRuCy2XHEAQ5O8A@mail.gmail.com>
 <31094.1502827694@sss.pgh.pa.us> <29231.1502831727@sss.pgh.pa.us>
 <CA+Tgmoa+h--4STWwP-+XkrSwcU8wWtNCV7ODcQZgyy=Xi+Np6g@mail.gmail.com>
 <7013.1502836842@sss.pgh.pa.us>
 <CA+TgmoYB4EfN4FkpWf3UFRgMgrA2Go7FgFmu-p7Yzh+WDx9E5A@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 15 Aug 2017 20:27:31 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23847.1502895834.1@sss.pgh.pa.us>
Date: Wed, 16 Aug 2017 11:03:54 -0400
Message-ID: <23848.1502895834@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 15, 2017 at 6:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (In fact, a quick look shows a counterexample: if we pick a MinMaxAgg
>> path, that's parallel unsafe, but the original query might've been
>> completely safe.)

> I'm quite confused here.  What's parallel-unsafe about a MinMaxAgg?
> There might be some reason why it's parallel-restricted, but it
> shouldn't be parallel-unsafe.

Well, it has subplans, so formally I think it's restricted not unsafe
--- but the parallel_safe marking on constructed paths/plans is only
safe/not-safe, not a three-way.  By the time we get back up to
standard_planner() and are considering whether to plaster a Gather on
top, it doesn't really matter whether that subtree is unsafe or merely
restricted; either way, you can't send it to a worker.

> More generally, there is no way for parallelModeOK to go from true to
> false after it's initially set.

Sure, and it's not necessary, because that's just a plan-time flag
indicating whether it's worth the trouble to look for parallel plans.
It is not an indicator that we will or must end up choosing a parallel
plan.  parallelModeNeeded is a different animal: it's a planner output
(which AFAICS is never consulted within the planner, so there's no need
to set it early) telling the executor whether to do
EnterParallelMode/ExitParallelMode.

> If there were, it would be a bug,
> because we might plan some subquery thinking that parallelModeOK is
> true, use a Gather node, and then later plan some other subquery that
> changes to parallelModeOK from true to false, making the plan that's
> already written in stone no longer valid.  This is exactly why we have
> to have max_parallel_hazard() walk the ENTIRE query tree, including
> all subqueries, before we get started.

> Planning can obviously introduce elements into the query that prevent
> parallelism from being used for that part of the query, and the only
> thing there is to make sure that such things never make it into a
> partial path.  But it can't just decide that parallelism is no longer
> allowed *anywhere* in the query.

These statements are true, but none of them seem at all relevant to
my point.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers