Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted |
Дата | |
Msg-id | 24051.1465570236@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Don't generate parallel paths for
rels with parallel-restricted
Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted |
Список | pgsql-hackers |
Amit Kapila <amit.kapila16@gmail.com> writes: > On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> Could you answer my question about whether adjust_appendrel_attrs() >>> might translate Vars into non-Vars? >> Yes, absolutely. > Isn't this true only for UNION ALL cases and not for inheritance child > relations (at least that is what seems to be mentioned in comments > for translated_vars in AppendRelInfo)? Correct. > If that is right, then I think > there shouldn't be a problem w.r.t parallel plans even if > adjust_appendrel_attrs() translate Vars into non-Vars, because for UNION > ALL it seems parent rels rtekind is RTE_SUBQUERY and we consider such rels > as parallel unsafe (see set_rel_consider_parallel()). Hm, that would explain why you haven't been able to exhibit a bug on HEAD as it stands; but it doesn't make the code any less broken on its own terms, or any less of a risk for future bugs when we try to relax the no-subqueries restriction. I am still of the opinion that reltarget_has_non_vars is simply a bad idea. It's wrong as-committed, it will be a permanent maintenance hazard, and there is no evidence that it saves anything meaningful even as the code stood yesterday, let alone after cae1c788b. I think we should just remove it and allow those has_parallel_hazard calls to occur unconditionally, and will go do that unless I hear some really good argument to the contrary. regards, tom lane
В списке pgsql-hackers по дате отправления: