Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my
От | Yeb Havinga |
---|---|
Тема | Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my |
Дата | |
Msg-id | 4F61B353.2010700@gmail.com обсуждение исходный текст |
Ответ на | EquivalenceClasses and subqueries and PlaceHolderVars, oh my (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my
|
Список | 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 по дате отправления: