Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: EquivalenceClasses and subqueries and PlaceHolderVars, oh my
Date: 2012-03-15 09:16:03
Message-ID: 4F61B353.2010700@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2012-03-15 09:50:44 Re: CREATE FOREGIN TABLE LACUNA
Previous Message Daniel Farina 2012-03-15 08:49:50 Another review of URI for libpq, v7 submission