Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Tue, 25 Aug 2015 06:11:45 +0000 (UTC)
From: "Gopal V (JIRA)" <jira@apache.org>
To: dev@hive.apache.org
Message-ID: <JIRA.12858524.1440483091000.155051.1440483105903@Atlassian.JIRA>
In-Reply-To: <JIRA.12858524.1440483091000@Atlassian.JIRA>
References: <JIRA.12858524.1440483091000@Atlassian.JIRA>
 <JIRA.12858524.1440483091946@arcas>
Subject: [jira] [Created] (HIVE-11638) ExprNodeDesc hashMap accidentally
 degrades into O(N) instead of O(1)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Gopal V created HIVE-11638:
------------------------------

             Summary: ExprNodeDesc hashMap accidentally degrades into O(N) instead of O(1)
                 Key: HIVE-11638
                 URL: https://issues.apache.org/jira/browse/HIVE-11638
             Project: Hive
          Issue Type: Bug
          Components: Logical Optimizer
    Affects Versions: 1.2.1, 1.1.1, 1.0.1, 0.14.0, 1.3.0, 2.0.0
            Reporter: Gopal V
            Assignee: Gopal V


Due to the absence of ExprNodeDesc::equals() & the presence of a hashCode(), any code which computes a Set or HashMap of identical objects ends up with a skewed hashmap which degrades column lookups from O(1) to O(N) during optimizer passes.

So, several hundred references to a single column desc will be stored in a single hashbucket, but since they default to Object::equals(), they are not equal to each other.

Finalize the equals() method, so that the approach from HIVE-10215 carries over safely.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)