Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my

Yeb Havinga <yebhavinga(at)gmail(dot)com> writes:
> On 2012-03-15 02:29, Tom Lane wrote:
>>> 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?

None of the known problems are the fault of that, really. The child
entries don't cause merging of ECs, which would be the only way that
they'd affect the semantics of the query at large. So in that sense
they are not really members of the EC but just some auxiliary entries
that ease figuring out whether a child expression matches an EC.

Having said that, I have been wondering whether there's a better way to
do that task. Right now prepare_sort_from_pathkeys has to do a lot of
fairly ugly, heuristic stuff to do that matching at all. The other
area of the code that has to match child expressions to ECs is index
path generation, and we already know that code isn't terribly happy with
the PHV-based solution either ...

regards, tom lane