calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: ProjectMergeRule
Date Tue, 21 Jul 2015 19:23:25 GMT
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
>>

Mime
View raw message