Re: assessing parallel-safety

On Sun, Feb 8, 2015 at 12:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Feb 8, 2015 at 11:31 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> On Sat, Feb 07, 2015 at 08:18:55PM -0500, Robert Haas wrote:
>>> There are a few problems with this design that I don't immediately
>>> know how to solve:
>>>
>>> 1. I'm concerned that the query-rewrite step could substitute a query
>>> that is not parallel-safe for one that is. The upper Query might
>>> still be flagged as safe, and that's all that planner() looks at.
>>
>> I would look at determining the query's parallel safety early in the planner
>> instead; simplify_function() might be a cheap place to check. Besides
>> avoiding rewriter trouble, this allows one to alter parallel safety of a
>> function without invalidating Query nodes serialized in the system catalogs.
>
> Thanks, I'll investigate that approach.

This does not seem to work out nicely. The problem here is that
simplify_function() gets called from eval_const_expressions() which
gets called from a variety of places, but the principal one seems to
be subquery_planner(). So if you have a query with two subqueries,
and the second one contains something parallel-unsafe, you might by
that time have already generated a parallel plan for the first one,
which won't do. 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.

Ideas?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company