let me check it out^_^
2017-06-21 0:25 GMT+08:00 Jim Apple :
> THis looks like the closest ticket to the question:
>
> https://issues.apache.org/jira/browse/IMPALA-2416
>
> Feel free to file another, more ambitious, ticket if you'd like.
>
> On Tue, Jun 20, 2017 at 4
Hi guys:
Is there a plan to implement the histogram support for computing column
stats? Base on my assumption, if the histogram support implements, it will
easily and more accurate to predict the join involved row numbers, and
which will make a better decision for choosing the shuffle or the bro
We have tested few days, it is 600seconds to fetch around 6GB data when
using big fetch size, 10MB per sec, the performance still has room to
improve for hive jdbc driver or impala front-end.
2017-04-29 14:32 GMT+08:00 yu feng :
> my pleasure.
>
> 2017-04-29 14:16 GMT+08:00 吴朱华 :
> http://server1.domain.com:25000/query_plan?query_id=ee421b6d4a2226d3:
> > 8acbb75f
> > Fetched 300 row(s) in 38.88s
> > 390M lineitem_3m_impala_shell.txt
> >
> > *real 0m39.152s*
> > user 0m26.012s
> > sys 0m0.668s
> >
> >
&
somewhere
> and
> post a link, though.
>
> On Thu, Apr 27, 2017 at 11:35 PM, 吴朱华 wrote:
>
> > Oops, I just resend it, you know the chinese network^_^
> >
> > 2017-04-28 14:20 GMT+08:00 Mostafa Mokhtar :
> >
> >> Btw the profile wasn't attached
Oops, I just resend it, you know the chinese network^_^
2017-04-28 14:20 GMT+08:00 Mostafa Mokhtar :
> Btw the profile wasn't attached.
> Please resend.
>
> On Thu, Apr 27, 2017 at 11:11 PM, 吴朱华 wrote:
>
>> Profile is in the attachment, thanks
>>
>>
Thu, Apr 27, 2017 at 9:30 PM, 吴朱华 wrote:
>
> > Hi guys:
> > we can facing a big issue when select * from a big table.
> > The performance is 17minutes for retrieving 400MB data. Even slow under
> > JDBC situation.
> > Is there anyway to improve it?^_^
> >
>
Hi guys:
we can facing a big issue when select * from a big table.
The performance is 17minutes for retrieving 400MB data. Even slow under
JDBC situation.
Is there anyway to improve it?^_^
Hi guys:
Is there any change on metadata loading? The metadata loading used to 10sec.
2017-03-23 12:42 GMT+08:00 吴朱华 :
> thx^_^
>
> 2017-03-23 11:51 GMT+08:00 Henry Robinson :
>
>> If your build does not have runtime filters (which are a little more than
>> a year old)
o directly to the
>> HMS's backing DB, you can query that.
>> What information are you looking for?
>>
>> Thanks.
>>
>> On Thu, Apr 6, 2017 at 3:02 PM, 吴朱华 wrote:
>> > Hi guys:
>> >
>> > Currently, we are using "show datab
Hi guys:
Currently, we are using "show databases","show tables" or "Describe table"
to retrieve table metadata, but we use such as "select * from metadata" to
retrieve, just like RDBMS did^_^
thx^_^
2017-03-23 11:51 GMT+08:00 Henry Robinson :
> If your build does not have runtime filters (which are a little more than
> a year old), then the answer is yes: you should upgrade.
>
> Performance in general has been improving steadily over the last year.
>
> On 22 March
The question is there any big join perf related improvement has
implemented? Thx
2017-03-23 11:34 GMT+08:00 吴朱华 :
> Hi guys:
>
> I am currently using my one year old build (I guess 2016.3 CDH5-Trunk),
> now I am facing a lot of join query situation(two big table joins), do I
> nee
Hi guys:
I am currently using my one year old build (I guess 2016.3 CDH5-Trunk), now
I am facing a lot of join query situation(two big table joins), do I need
to upgrade my one year old build for potential join perf improvement? Thx
at advance^_^
without full-fledged support for UDAnFs.
>
> Alex
>
>
> On Thu, Dec 15, 2016 at 7:42 PM, 吴朱华 wrote:
>
> > Hi guys:
> >
> > Some of my clients are consider switching from vertica to impala, but
> they
> > really need the UDAnF to speed up the query. Is there any plans for
> > supporting UDAnF?^_^
> >
>
Hi guys:
Some of my clients are consider switching from vertica to impala, but they
really need the UDAnF to speed up the query. Is there any plans for
supporting UDAnF?^_^
16 matches
Mail list logo
