Mailing-List: contact issues-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@impala.incubator.apache.org
Date: Thu, 29 Jun 2017 23:05:00 +0000 (UTC)
From: "Matthew Jacobs (JIRA)" <jira@apache.org>
To: issues@impala.incubator.apache.org
Message-ID: <JIRA.13083626.1498777498000.139718.1498777500211@Atlassian.JIRA>
In-Reply-To: <JIRA.13083626.1498777498000@Atlassian.JIRA>
References: <JIRA.13083626.1498777498000@Atlassian.JIRA> <JIRA.13083626.1498777498804@jira-lw-us.apache.org>
Subject: [jira] [Created] (IMPALA-5602) All predicates pushed to Kudu with
 limit runs incorrectly as 'small query'
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 29 Jun 2017 23:05:05 -0000

Matthew Jacobs created IMPALA-5602:
--------------------------------------

             Summary: All predicates pushed to Kudu with limit runs incorrectly as 'small query'
                 Key: IMPALA-5602
                 URL: https://issues.apache.org/jira/browse/IMPALA-5602
             Project: IMPALA
          Issue Type: Bug
          Components: Frontend
    Affects Versions: Impala 2.8.0
            Reporter: Matthew Jacobs


When Kudu scans have predicates pushed to Kudu, the base implementation of  {{ScanNode.getInputCardinality()}} is wrong:

{code}
  @Override
  public long getInputCardinality() {
    if (getConjuncts().isEmpty() && hasLimit()) return getLimit();
    return inputCardinality_;
  }
{code}

getConjuncts() won't contain the predicates pushed to Kudu. If such a query has a limit and there aren't any conjuncts applied at the scan node, then this function will return the limit as the input cardinality mistakenly.

This can result in a query running with the "small query" optimization when it should not be, i.e. it runs on a single node with a single scanner thread.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)