From dev-return-23660-apmail-phoenix-dev-archive=phoenix.apache.org@phoenix.apache.org Wed Dec 16 11:46:48 2015 Return-Path: X-Original-To: apmail-phoenix-dev-archive@minotaur.apache.org Delivered-To: apmail-phoenix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 864B918601 for ; Wed, 16 Dec 2015 11:46:48 +0000 (UTC) Received: (qmail 13619 invoked by uid 500); 16 Dec 2015 11:46:48 -0000 Delivered-To: apmail-phoenix-dev-archive@phoenix.apache.org Received: (qmail 13559 invoked by uid 500); 16 Dec 2015 11:46:48 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 13519 invoked by uid 99); 16 Dec 2015 11:46:48 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2015 11:46:48 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 9484D1804A5 for ; Wed, 16 Dec 2015 11:46:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.226 X-Spam-Level: * X-Spam-Status: No, score=1.226 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.554] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id up1fMyCq7VdY for ; Wed, 16 Dec 2015 11:46:47 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with SMTP id D996C20424 for ; Wed, 16 Dec 2015 11:46:46 +0000 (UTC) Received: (qmail 13506 invoked by uid 99); 16 Dec 2015 11:46:46 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2015 11:46:46 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 96CC32C0452 for ; Wed, 16 Dec 2015 11:46:46 +0000 (UTC) Date: Wed, 16 Dec 2015 11:46:46 +0000 (UTC) From: "ramkrishna.s.vasudevan (JIRA)" To: dev@phoenix.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (PHOENIX-1312) Do not always project the empty column family MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated PHOENIX-1312: -------------------------------------------- Attachment: PHOENIX-1312_v3.patch Udpated patch that projects the CF in where clause and allows the guide posts also to be picked up based on the CF in the where clause. If not found it will allow the default CF to be used. But in the case where there is a COUNT(*) query with a where clause then the projection happens only with the default case. So we are using the default CF only. Is that fine? Because in TupleProjectionCompiler we have this {code} Preconditions.checkArgument(!select.isJoin()); // Non-group-by or group-by aggregations will create its own projected result. if (select.getInnerSelectStatement() != null || select.getFrom() == null || select.isAggregate() || select.isDistinct() || (context.getResolver().getTables().get(0).getTable().getType() != PTableType.TABLE && context.getResolver().getTables().get(0).getTable().getType() != PTableType.INDEX && context.getResolver().getTables().get(0).getTable().getType() != PTableType.VIEW)) return null; {code} > Do not always project the empty column family > --------------------------------------------- > > Key: PHOENIX-1312 > URL: https://issues.apache.org/jira/browse/PHOENIX-1312 > Project: Phoenix > Issue Type: Bug > Reporter: James Taylor > Assignee: ramkrishna.s.vasudevan > Fix For: 4.7.0 > > Attachments: PHOENIX-1312_1.patch, PHOENIX-1312_v2.patch, PHOENIX-1312_v3.patch, Phoenix-1312.patch > > > Often times, we don't need to, but it seems we always are. See MultiCfQueryExecIT.testGuidePostsForMultiCFs() where we run a query like this: > {code} > SELECT count(*) FROM multi_cf WHERE e.cpu_utilization IS NOT NULL > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)