Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jun 21, 2016 at 1:28 PM, Tom Lane <t...@sss.pgh.pa.us> 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
