Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 4A791200B78 for ; Fri, 2 Sep 2016 19:18:58 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 48FD5160AAE; Fri, 2 Sep 2016 17:18:58 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 8FF30160A8C for ; Fri, 2 Sep 2016 19:18:57 +0200 (CEST) Received: (qmail 85279 invoked by uid 500); 2 Sep 2016 17:18:56 -0000 Mailing-List: contact notifications-help@asterixdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@asterixdb.apache.org Delivered-To: mailing list notifications@asterixdb.apache.org Received: (qmail 85270 invoked by uid 99); 2 Sep 2016 17:18:56 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2016 17:18:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 69E77C0439 for ; Fri, 2 Sep 2016 17:18:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.126 X-Spam-Level: ** X-Spam-Status: No, score=2.126 tagged_above=-999 required=6.31 tests=[MISSING_HEADERS=1.207, SPF_FAIL=0.919] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id GQjjrifTRlcR for ; Fri, 2 Sep 2016 17:18:54 +0000 (UTC) Received: from unhygienix.ics.uci.edu (unhygienix.ics.uci.edu [128.195.14.130]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 5A1D45F252 for ; Fri, 2 Sep 2016 17:18:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by unhygienix.ics.uci.edu (Postfix) with ESMTP id 03AB4241EBF; Fri, 2 Sep 2016 10:18:54 -0700 (PDT) Date: Fri, 2 Sep 2016 10:18:53 -0700 From: "Wenhai Li (Code Review)" CC: Jenkins , Yingyi Bu , Yingyi Bu , Taewoo Kim , Chen Li , Jianfeng Jia , Till Westmann Reply-To: lwhaymail@yahoo.com X-Gerrit-MessageType: comment Subject: Change in asterixdb[master]: ASTERIX-1487: fix the wrong plan for inverted fuzzyjoin. X-Gerrit-Change-Id: I1aef69a2278853fd9f8020da6639331b367ed5ad X-Gerrit-ChangeURL: X-Gerrit-Commit: e3651f674958d6dfde47a68faec2770a87773327 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline User-Agent: Gerrit/2.8.4 Message-Id: <20160902171854.03AB4241EBF@unhygienix.ics.uci.edu> archived-at: Fri, 02 Sep 2016 17:18:58 -0000 Wenhai Li has posted comments on this change. Change subject: ASTERIX-1487: fix the wrong plan for inverted fuzzyjoin. ...................................................................... Patch Set 8: @Chen It's a quite strange query, the high-level comments towards the example is like: 1. We setup a fuzzy join over A.a ~= B.b based on a word index over A.a 2. We want to aggregate on B's fields. If we switch the consequence of A and B in the two "FOR" lines, we get inconsistent result. The RemoveUnusedOneToOneEuquiJoinRule remove the branch of A after "pseudo" broadcase B to A for enabling "SELECT" instead of fuzzy join. But that is wrong. -- To view, visit https://asterix-gerrit.ics.uci.edu/1119 To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1aef69a2278853fd9f8020da6639331b367ed5ad Gerrit-PatchSet: 8 Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Owner: Wenhai Li Gerrit-Reviewer: Chen Li Gerrit-Reviewer: Jenkins Gerrit-Reviewer: Jianfeng Jia Gerrit-Reviewer: Taewoo Kim Gerrit-Reviewer: Till Westmann Gerrit-Reviewer: Wenhai Li Gerrit-Reviewer: Yingyi Bu Gerrit-Reviewer: Yingyi Bu Gerrit-HasComments: No