Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my

Yeb Havinga <yebhavinga@gmail.com>

From: Yeb Havinga <yebhavinga@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Date: 2012-03-15T09:16:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix pushing of index-expression qualifications through UNION ALL.

  2. Wrap appendrel member outputs in PlaceHolderVars in additional cases.

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