Teodor Sigaev <teodor@sigaev.ru> writes:
> SELECT
> t1, t2
> FROM (
> SELECT t1, t2 FROM wow
> UNION ALL
> SELECT 'a', 'a' FROM wow
> ) t
> ORDER BY t1, t2;
Hmm, interesting.
> It's seems to me that check in create_merge_append_plan() is too restrictive:
> if (memcmp(sortColIdx, node->sortColIdx,
> numsortkeys * sizeof(AttrNumber)) != 0)
> elog(ERROR, "MergeAppend child's targetlist doesn't match
> MergeAppend");
No, it isn't. That code is fine; the problem is that
add_child_rel_equivalences is generating an invalid state of the
EquivalenceClass structures by adding equal items to two different
EquivalenceClasses. We need to rethink what that routine is doing.
It's definitely wrong for it to add constant items; here, that would
imply injecting t1 = 'a' and t2 = 'a' conditions, which is not correct.
> And the same problem is observed if second
> select is replaced by "SELECT t1, t1 FROM wow".
And this one is a bit nasty too, since it would still add equal items
to two different ECs, leading to the conclusion that they should be
merged, ie t1 = t2, which is likewise wrong.
Not immediately sure what to do about this. The quick-and-dirty fix
would be to only apply add_child_rel_equivalences to simple inheritance
child relations, for which the added items must be Vars and must be
different (which is what that code is expecting). Seems like a bit of a
shame to lobotomize planning for UNION cases, though. Maybe we need a
more complicated representation of child EquivalenceClass members.
regards, tom lane