Re: assessing parallel-safety

On Wed, Feb 11, 2015 at 03:21:12PM -0500, Robert Haas wrote:
> On Wed, Feb 11, 2015 at 9:39 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.

That is a major mark against putting the check in simplify_function(), agreed.

> > 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. The cost may just not
matter. Other parts of the planner use code like contain_volatile_functions()
and contain_nonstrict_functions(), which have the same kind of inefficiency
you're looking to avoid here.

> I think we may want a dedicated parallel-safe property for functions
> rather than piggybacking on provolatile, but that will probably also
> be changeable via ALTER FUNCTION, and stored rules won't get
> miraculously updated. So this definitely can't be something we figure
> out at parse-time ... it's got to be determined later.

Pretty much.

> But at the
> moment I see no way to do that without an extra pass over the whole
> rewritten query tree. :-(

+1 for doing that.