Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Wed, 7 Jan 2015 18:32:34 +0000 (UTC)
From: "Mostafa Mokhtar (JIRA)" <jira@apache.org>
To: hive-dev@hadoop.apache.org
Message-ID: <JIRA.12765268.1420594201000.30218.1420655554793@Atlassian.JIRA>
In-Reply-To: <JIRA.12765268.1420594201000@Atlassian.JIRA>
References: <JIRA.12765268.1420594201000@Atlassian.JIRA>
 <JIRA.12765268.1420594201445@arcas>
Subject: [jira] [Updated] (HIVE-9277) Hybrid Hybrid Grace Hash Join
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HIVE-9277?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mostafa Mokhtar updated HIVE-9277:
----------------------------------
    Assignee:     (was: Mostafa Mokhtar)

> Hybrid Hybrid Grace Hash Join
> -----------------------------
>
>                 Key: HIVE-9277
>                 URL: https://issues.apache.org/jira/browse/HIVE-9277
>             Project: Hive
>          Issue Type: New Feature
>          Components: Physical Optimizer
>            Reporter: Wei Zheng
>              Labels: join
>
> We are proposing an enhanced hash join algorithm called =E2=80=9Chybrid h=
ybrid grace hash join=E2=80=9D. We can benefit from this feature as illustr=
ated below:
> o The query will not fail even if the estimated memory requirement is sli=
ghtly wrong
> o Expensive garbage collection overhead can be avoided when hash table gr=
ows
> o Join execution using a Map join operator even though the small table do=
esn't fit in memory as spilling some data from the build and probe sides wi=
ll still be cheaper than having to shuffle the large fact table
> The design was based on Hadoop=E2=80=99s parallel processing capability a=
nd significant amount of memory available.


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