Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia |
Дата | |
Msg-id | 16315.1466538226@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Try again to fix the way the scanjoin_target is used with partia (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Jun 21, 2016 at 1:28 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: