Robert Haas <> writes:
> On Tue, Jun 21, 2016 at 1:28 PM, Tom Lane <> wrote:
>> Also, I got rid of the target_parallel argument to
>> apply_projection_to_path, as I thought that that was just way too much
>> interconnection between apply_projection_to_path and its callers than
>> is justified for what it saves (namely one call of has_parallel_hazard
>> when planning a Gather).  In general, having that argument could *add*
>> extra calls of has_parallel_hazard, since callers might have to do
>> that computation whether or not a Gather is present.

> I had a feeling you weren't going to like that, but it also didn't
> seem great to redo that computation for every path.  Right now, we
> only need it for Gather paths, but if we start marking subquery RTEs
> as parallel-safe and fix upper rels to correctly set
> consider_parallel, I have a feeling this is going to be needed more.
> But feel free to ignore that for now since I don't have a completely
> well-thought-out theory on this.

If that does start being a problem, I'd be inclined to address it by
teaching PathTarget to track whether its contents are parallel-safe.
For now, though, I think we don't need the complication.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to