On Fri, Jun 10, 2016 at 10:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Thu, Jun 9, 2016 at 11:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmh...@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.
OK. We can always revisit it another time if need be. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
