Re: pgsql: Don't generate parallel paths for rels with parallel-restricted
От | Tom Lane |
---|---|
Тема | Re: pgsql: Don't generate parallel paths for rels with parallel-restricted |
Дата | |
Msg-id | 5569.1465491729@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pgsql: Don't generate parallel paths for rels with parallel-restricted (Robert Haas <rhaas@postgresql.org>) |
Список | pgsql-committers |
Robert Haas <rhaas@postgresql.org> writes: > Don't generate parallel paths for rels with parallel-restricted outputs. Surely this bit is wrong on its face: @@ -971,6 +980,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel, adjust_appendrel_attrs(root, (Node *) rel->reltarget->exprs, appinfo); + childrel->reltarget_has_non_vars = rel->reltarget_has_non_vars; /* * We have to make child entries in the EquivalenceClass data The entire point of what we are doing here is that Vars might get replaced with things that are not Vars. See the comment a dozen lines above. More generally, if we need such a flag (which I doubt really), perhaps it should be part of PathTarget rather than expecting that it can successfully be maintained separately? It seems like the only reason that we would need such a flag is that applying has_parallel_hazard() to a Var is a bit expensive thanks to the typeid_is_temp() test --- but if you ask me, that test is stupid and should be removed. What's the argument for supposing that a temp table's rowtype is any more mutable intra-query than any other rowtype? regards, tom lane
В списке pgsql-committers по дате отправления: