Mailing-List: contact dev-help@calcite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@calcite.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKa9qDkPxq5oMPyFgJZuru9n+cuGFRdDDT=pQnBtpSKk9aZYfA@mail.gmail.com>
References: 
 <CAPSgeETpXp7Zq-L=ipMaTXW4uE1eCHrp2-tWBj2BiB1F5fFLSg@mail.gmail.com>
	<CAKa9qDkPxq5oMPyFgJZuru9n+cuGFRdDDT=pQnBtpSKk9aZYfA@mail.gmail.com>
Date: Tue, 21 Jul 2015 12:23:25 -0700
Message-ID: 
 <CAPSgeER=b092Yw21i7d5wLftWp1gn8yQQJ97rqt2iQkZmQ6=OQ@mail.gmail.com>
Subject: Re: ProjectMergeRule
From: Julian Hyde <jhyde@apache.org>
To: dev@calcite.incubator.apache.org
Content-Type: text/plain; charset=UTF-8

Jacques,

I can make the default instance (ProjectMergeRule.INSTANCE) have
force=true (currently it has force=false) and only remove a renaming
project if force=true. Then most people will get the benefit, but if
there is a problem you can switch Drill to using a custom instance.

Also, this would be good reason to test Drill against a 1.4-SNAPSHOT
when it is posted.

Julian


On Tue, Jul 21, 2015 at 11:18 AM, Jacques Nadeau <jacques@apache.org> wrote:
> I'm a little nervous about that for Drill.  Despite the goal to do full
> testing to make sure we weren't accidentally using field names anywhere, we
> haven't yet gotten very far.  We know we're not supposed to depend on
> anything but ordinal but as a name based system, it is likely something
> depends on something there.
>
> On Tue, Jul 21, 2015 at 11:04 AM, Julian Hyde <jhyde@apache.org> wrote:
>
>> ProjectMergeRule currently refuses to reduce identity projects if the
>> fields have different names.
>>
>> For instance suppose you have a table Dept (deptno, name) and the algebra
>>
>>   2: Project($1 as X, $0 as Y)
>>     1: Project($1, $0)
>>       0: Scan(Dept)
>>
>> Observe that if you combine projects #1 and #2 you end up with
>>
>>   3: Project($0 as X, $1 as Y)
>>     0: Scan(Dept)
>>
>> Although the new project (#3) is an identity, it renames the fields.
>> ProjectMergeRule will return the new project (#3), but it could return
>> Scan(Dept) (#0).
>>
>> Does anyone think they will break if I make it return #0?
>>
>> Julian
>>