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