On 2012-03-15 02:29, Tom Lane wrote: > > explain select * from > (select thousand as t1, tenthous as t2 from tenk1 a > union all > select 42 as t1, 42 as t2 from tenk1 b) c > order by t1, t2; > > There is an EquivalenceClass for each of "t1" and "t2", and if we don't > do something like wrapping the constants with distinct PHVs, then > add_child_rel_equivalences will end up pushing identical constants into > both ECs, thus totally bollixing the fundamental rule that any expression > should match at most one EC.
I'm having a hard time imagining that add_child_rel_equivalences is not just plain wrong. Even though it will only add child equivalence members to a parent eq class when certain conditions are met, isn't it the case that since a union (all) is addition of tuples and not joining, any kind of propagating restrictions on a append rel child member to other areas of the plan can cause unwanted results, like the ones currently seen?
regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
