Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@impala.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAAzK7q9qQP4syHA71A84BygEGQ==hUqdZdyeJZZCL1YgNrFBOw@mail.gmail.com>
References: <CAPprPdShw21PRi-UprEEVsosKnso_j67+X9iq4+L3w3LNEvpFA@mail.gmail.com>
 <CAAzK7q9qQP4syHA71A84BygEGQ==hUqdZdyeJZZCL1YgNrFBOw@mail.gmail.com>
From: yu feng <olaptestyu@gmail.com>
Date: Mon, 8 May 2017 09:45:45 +0800
Message-ID: <CAPprPdTeWySmiW03DUAh60DC04TV6_GVuozm+fiY7FkadSixeA@mail.gmail.com>
Subject: Re: about broadcast join and hash shuffle join
To: dev@impala.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113c5860d52d9d054ef96508
archived-at: Mon, 08 May 2017 01:45:51 -0000

--001a113c5860d52d9d054ef96508
Content-Type: text/plain; charset=UTF-8

Great! I agree to defaulting to partitioned joins should reduce the risk of
disastrous plans.

2017-05-05 22:20 GMT+08:00 Thomas Tauber-Marshall <tmarshall@cloudera.com>:

> There's actually a review out right now for changing the default join
> algorithm when stats are unavailable to partitioned:
> https://gerrit.cloudera.org/#/c/6803/
>
> On Fri, May 5, 2017 at 4:44 AM yu feng <olaptestyu@gmail.com> wrote:
>
> > Hi All:
> >
> > I find impala choose join algorithm by comparing data transmission size
> > between broad cast and shuffle join while generating physical execution
> > plan. what I am confused is why impala choose broadcast as default
> > implement(such as table do not compute stats) ?
> >
> > In my experience, shuffle join maybe the better choice, and some of my
> > queries use broadcast join between two subquery with huge resultset and
> the
> > query costs has difference up to ten times (8s and 80s).
> >
> > I think user should always compute stats for every partition, do you guys
> > have some good suggestion about this.
> >
> > Thanks a lot
> >
>

--001a113c5860d52d9d054ef96508--