On Tue, Aug 15, 2017 at 6:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No. The case that I'm concerned about is where the initial estimate
> of "parallelModeOK" is true, but the planner nevertheless selects
> a parallel-unsafe plan --- unsafe for some other reason than that it
> already has a Gather in it. That would prevent the code further down
> in standard_planner from plastering a Gather on top, but we still end up
> labeling the output plan with parallelModeNeeded = true.
>
> Now, you might argue that there should be no case where that initial
> estimate has parallelModeOK = true and yet we end up with a
> parallel-unsafe plan. I do not think I believe that; that estimate
> is supposed to be a conservative estimate, not ironclad exactness.
> (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.
More generally, there is no way for parallelModeOK to go from true to
false after it's initially set. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company