Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my
Date
Msg-id 4F61B353.2010700@gmail.com
Whole thread Raw
In response to EquivalenceClasses and subqueries and PlaceHolderVars, oh my  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2012-03-15 02:29, Tom Lane wrote:>> explain select * from>  (select thousand as t1, tenthous as t2 from tenk1 a>
unionall>   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
willend up pushing identical constants into> both ECs, thus totally bollixing the fundamental rule that any expression>
shouldmatch 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



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Another review of URI for libpq, v7 submission
Next
From: Etsuro Fujita
Date:
Subject: Re: CREATE FOREGIN TABLE LACUNA