Mailing-List: contact user-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hive.apache.org
Received-SPF: pass (athena.apache.org: domain of kwiley@keithwiley.com
 designates 69.93.243.6 as permitted sender)
From: Keith Wiley <kwiley@keithwiley.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Query crawls through reducer
Date: Fri, 22 Mar 2013 16:02:24 -0700
Message-Id: <098EF9B7-D25E-443F-A937-6E2C5B633061@keithwiley.com>
To: user@hive.apache.org
Mime-Version: 1.0 (Apple Message framework v1085)

The following query translates into a many-map-single-reduce job (which =
is common) and also slags through the reduce stage...it's killing the =
overall query:

select * from a where b >=3D 'c' order by b desc limit 100

Note that b is a partition.  What component is making the reducer heavy? =
 Is it the order by or the limit (I'm sure it's not the =
partition-specific where clause, right?)?  Are there ways to improve its =
performance?

=
__________________________________________________________________________=
______
Keith Wiley     kwiley@keithwiley.com     keithwiley.com    =
music.keithwiley.com

"You can scratch an itch, but you can't itch a scratch. Furthermore, an =
itch can
itch but a scratch can't scratch. Finally, a scratch can itch, but an =
itch can't
scratch. All together this implies: He scratched the itch from the =
scratch that
itched but would never itch the scratch from the itch that scratched."
                                           --  Keith Wiley
=
__________________________________________________________________________=
______