From dev-return-1503-apmail-calcite-dev-archive=calcite.apache.org@calcite.incubator.apache.org Tue Jul 21 22:13:45 2015 Return-Path: X-Original-To: apmail-calcite-dev-archive@www.apache.org Delivered-To: apmail-calcite-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ABEFB18325 for ; Tue, 21 Jul 2015 22:13:45 +0000 (UTC) Received: (qmail 29930 invoked by uid 500); 21 Jul 2015 22:13:45 -0000 Delivered-To: apmail-calcite-dev-archive@calcite.apache.org Received: (qmail 29865 invoked by uid 500); 21 Jul 2015 22:13:45 -0000 Mailing-List: contact dev-help@calcite.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@calcite.incubator.apache.org Delivered-To: mailing list dev@calcite.incubator.apache.org Received: (qmail 29854 invoked by uid 99); 21 Jul 2015 22:13:45 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jul 2015 22:13:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E6E62D680D for ; Tue, 21 Jul 2015 22:13:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.753 X-Spam-Level: ** X-Spam-Status: No, score=2.753 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.227] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id oBcer9MbcHtE for ; Tue, 21 Jul 2015 22:13:40 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with SMTP id 7191B2302F for ; Tue, 21 Jul 2015 22:13:39 +0000 (UTC) Received: (qmail 29663 invoked by uid 99); 21 Jul 2015 22:13:38 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jul 2015 22:13:38 +0000 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 389FA1A0040 for ; Tue, 21 Jul 2015 22:13:37 +0000 (UTC) Received: by qkdl129 with SMTP id l129so142677354qkd.0 for ; Tue, 21 Jul 2015 15:13:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.20.24 with SMTP id e24mr58474493qkh.35.1437516816169; Tue, 21 Jul 2015 15:13:36 -0700 (PDT) Received: by 10.96.48.194 with HTTP; Tue, 21 Jul 2015 15:13:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 15:13:36 -0700 Message-ID: Subject: Re: ProjectMergeRule From: Jacques Nadeau To: dev@calcite.incubator.apache.org Content-Type: multipart/alternative; boundary=001a113a14702fc433051b69f70a --001a113a14702fc433051b69f70a Content-Type: text/plain; charset=UTF-8 I'd love the other Drill guys to chime here on their thoughts. Your suggestion makes sense. I'm not sure that Drill will have a problem since we do a final tree rewrite to avoid the name inconsistency issue. On Tue, Jul 21, 2015 at 12:23 PM, Julian Hyde wrote: > 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 > 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 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 > >> > --001a113a14702fc433051b69f70a--