Return-Path: X-Original-To: apmail-hive-user-archive@www.apache.org Delivered-To: apmail-hive-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8ABE4184B7 for ; Wed, 22 Jul 2015 16:38:45 +0000 (UTC) Received: (qmail 65193 invoked by uid 500); 22 Jul 2015 16:38:30 -0000 Delivered-To: apmail-hive-user-archive@hive.apache.org Received: (qmail 65123 invoked by uid 500); 22 Jul 2015 16:38:30 -0000 Mailing-List: contact user-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hive.apache.org Delivered-To: mailing list user@hive.apache.org Received: (qmail 65113 invoked by uid 99); 22 Jul 2015 16:38:30 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jul 2015 16:38:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 075E01A763C for ; Wed, 22 Jul 2015 16:38:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.98 X-Spam-Level: ** X-Spam-Status: No, score=2.98 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id KpHhh6mOpnJy for ; Wed, 22 Jul 2015 16:38:28 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 4297126429 for ; Wed, 22 Jul 2015 16:38:28 +0000 (UTC) Received: by lagw2 with SMTP id w2so141457416lag.3 for ; Wed, 22 Jul 2015 09:38:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nTGXzAe4JWlnCQ63ALA0aBU02U5BW490PiUowShn1AI=; b=SfRDHKYf4BAxiQMSZHF0/GSf5cu3pWEWJXuboSv2pa8f4l9cfno92NyXmRWm4hyEeD MGl9lp9TJBeS4rz462n4dyFbTSpWrFuE35hzVwqzJjzVVvfr2dMRklAhUE42VB00DcoL Wle29oeAXMq0YFjz/R9hAtiNDQ1sR8l3FlXfXi86g4qq/nKyVkmQkbWFApk0O/YeZghX Z6hcDWvE9tXtmhuE1Q1yaVEKT9pb8pNZDio9DuoVkHOBTgGFJvgWbRQQneVVS9kDjgnc 8KapdquwTL12oxE3g0DK9xSRBOeMFzsYFIId4RsrT0J+DmZANVv81r+eN1/VqSTV1nx7 TBnA== X-Gm-Message-State: ALoCoQnA/VrLukc2Qb7VBYSo7bLPOmj6IfI7G/9HC7wR1ugjKobXI06W8G2gU7zKTM8O9lGCTi10 MIME-Version: 1.0 X-Received: by 10.152.10.72 with SMTP id g8mr3160032lab.97.1437583106634; Wed, 22 Jul 2015 09:38:26 -0700 (PDT) Received: by 10.112.63.197 with HTTP; Wed, 22 Jul 2015 09:38:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2015 09:38:26 -0700 Message-ID: Subject: Re: limit clause + fetch optimization From: Adam Silberstein To: Gopal Vijayaraghavan Cc: "user@hive.apache.org" Content-Type: multipart/alternative; boundary=001a1132efa2681494051b7966af --001a1132efa2681494051b7966af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Gopal. I filed an issue to cover JDBC+setMaxRows: https://issues.apache.org/jira/browse/HIVE-11342 For your first offer of testing a patch, unfortunately we tend to run our production software on customers' Hadoop clusters, so we can't easily patch their Hive instances. But I'll still take you up on that if I find some time to try it. Thanks, Adam On Tue, Jul 21, 2015 at 11:14 PM, Gopal Vijayaraghavan wrote: > > > Just want to make sure I understand the behavior once that bug is > >fixed...a 'select *' with no limit will run without a M/R job and instea= d > >stream. Is that correct? > > Yes, that=C2=B9s the intended behaviour. I can help you get a fix in, if = you > have some time to test out my WIP patches. > > > That may incidently solve another bug I'm seeing: when you use JDBC > >templates to set the limit (setMaxRows in Spring in my setup), it does > >not avoid the M/R job (and no limit clause appears in the hive-server2 > >log). Instead, the M/R job gets launched...I'm > > not sure if the jdbc framework subsequently would apply a limit, once > >the job finishes. I haven't spotted this issue in JIRA, I'd be happy to > >file it if that's useful to you. > > File a JIRA, would be very useful for me. > > There=C2=B9s a lot of low-hanging fruit in the JDBC + Prepared Statement > codepath, so going over the issues & filing your findings would help me > pick up and knock them off one by one when I=C2=B9m back. > > Prasanth=C2=B9s github has some automated benchmarking tools for JDBC, wh= ich I > use heavily - https://github.com/prasanthj/jmeter-hiveserver2/tree/llap > > > There are some known issues which have a 2-3x perf degradation for the > simple query patterns you=C2=B9re running, like - > https://issues.apache.org/jira/browse/HIVE-10982 > > Cheers, > Gopal > > > --001a1132efa2681494051b7966af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Gopal.=C2=A0 I filed an issue to cover JDBC+setMaxR= ows:=C2=A0http= s://issues.apache.org/jira/browse/HIVE-11342

For you= r first offer of testing a patch, unfortunately we tend to run our producti= on software on customers' Hadoop clusters, so we can't easily patch= their Hive instances.=C2=A0 But I'll still take you up on that if I fi= nd some time to try it.

Thanks,
Adam

On Tue, J= ul 21, 2015 at 11:14 PM, Gopal Vijayaraghavan <gopalv@apache.org> wrote:

> Just want to make sure I understand the behavior once that bug is
>fixed...a 'select *' with no limit will run without a M/R job a= nd instead
>stream.=C2=A0 Is that correct?

Yes, that=C2=B9s the intended behaviour. I can help you get a fix in= , if you
have some time to test out my WIP patches.

> That may incidently solve another bug I'm seeing: when you use JDB= C
>templates to set the limit (setMaxRows in Spring in my setup), it does<= br> >not avoid the M/R job (and no limit clause appears in the hive-server2<= br> >log).=C2=A0 Instead, the M/R job gets launched...I'm
> not sure if the jdbc framework subsequently would apply a limit, once<= br> >the job finishes.=C2=A0 I haven't spotted this issue in JIRA, I'= ;d be happy to
>file it if that's useful to you.

File a JIRA, would be very useful for me.

There=C2=B9s a lot of low-hanging fruit in the JDBC + Prepared Statement codepath, so going over the issues & filing your findings would help me=
pick up and knock them off one by one when I=C2=B9m back.

Prasanth=C2=B9s github has some automated benchmarking tools for JDBC, whic= h I
use heavily - https://github.com/prasanthj/= jmeter-hiveserver2/tree/llap


There are some known issues which have a 2-3x perf degradation for the
simple query patterns you=C2=B9re running, like -
https://issues.apache.org/jira/browse/HIVE-10982=

Cheers,
Gopal



--001a1132efa2681494051b7966af--