Now that Impala 3.4 is branched and master is Impala 4.0, we need to decide
what breaking changes will happen in Impala 4.0. I have provided a series
of proposals below. I welcome feedback on them. Other proposals are also
welcome.
Thanks,
Joe
Proposal 0: Hadoop component versions
Switch to CDP
Looking forward to Proposal 3! Getting lzo out of the core tests would help
solve most of my random test data loading issues.
On Mon, Mar 16, 2020 at 1:07 PM Joe McDonnell
wrote:
> Now that Impala 3.4 is branched and master is Impala 4.0, we need to decide
> what breaking changes will happen in
s
> Zhao Renhai
>
>
> 发件人: Joe McDonnell
> 发送时间: 2020年3月17日 1:07
> 收件人: dev@impala.apache.org
> 主题: Impala 4.0 breaking changes
>
> Now that Impala 3.4 is branched and master is Impala 4.0, we need to decide
> what breaking changes will happen in Impala
; Could we add support for arm64?
> >
> > Thanks
> > Zhao Renhai
> >
> >
> > 发件人: Joe McDonnell
> > 发送时间: 2020年3月17日 1:07
> > 收件人: dev@impala.apache.org
> > 主题: Impala 4.0 breaking changes
> >
> > Now that Impala 3.4 is branched
I think I generally support this. A few specific comments.
> Proposal 3: Impala-lzo
> Drop support for Impala-lzo/hadoop-lzo
Does this mean dropping the plugin text scanner interface entirely? LZO is
the only implementation of that that I'm aware of (and we rely on it to
test the interface) so se
> - Do we still need the DECIMAL_V2 query option? Seems like this has
been true for a while. Maybe we can add it to the list of deprecated flags?
Maybe we could officially deprecate it and phase it out soonish? It really
only exists as a workaround for people upgrading from the old behaviour in
I think we should consider changing a couple more defaults, after having an
offline conversion with Shant.
We could change COMPRESSION_CODEC to LZ4 or ZSTD as the default. I think
LZ4 is the safest option perf-wise, because it will be faster across the
board and the decompression is now one of the
+1 on RUNTIME_FILTER_WAIT_TIME_MS increasing.
On Tue, Mar 17, 2020 at 5:43 PM Tim Armstrong wrote:
>
> I think we should consider changing a couple more defaults, after having an
> offline conversion with Shant.
>
> We could change COMPRESSION_CODEC to LZ4 or ZSTD as the default. I think
> LZ4 is
What do you think about dateless timestamps? AFAIK that is not supported
ATM, shouldn't we drop it?
Gabor
On Wed, Mar 18, 2020 at 1:46 AM Shant Hovsepian wrote:
> +1 on RUNTIME_FILTER_WAIT_TIME_MS increasing.
>
> On Tue, Mar 17, 2020 at 5:43 PM Tim Armstrong
> wrote:
> >
> > I think we should
> What do you think about dateless timestamps? AFAIK that is not supported
+1, I think that dateless timestamps are just confusing both in the code
and for the users
I created a Jira to drop it: IMPALA-9531
A number of issues with them are listed in this jira: IMPALA-5942
On Wed, Mar 18, 2020 at 3
时间: 2020年3月17日 1:07
> 收件人: dev@impala.apache.org
> 主题: Impala 4.0 breaking changes
>
> Now that Impala 3.4 is branched and master is Impala 4.0, we need to decide
> what breaking changes will happen in Impala 4.0. I have provided a series
> of proposals below. I welcome feedback on them
Response inline:
On Tue, Mar 17, 2020 at 11:51 AM Tim Armstrong
wrote:
> I think I generally support this. A few specific comments.
>
> > Proposal 3: Impala-lzo
> > Drop support for Impala-lzo/hadoop-lzo
>
> Does this mean dropping the plugin text scanner interface entirely? LZO is
> the only im
___
> > 发件人: Joe McDonnell
> > 发送时间: 2020年3月17日 1:07
> > 收件人: dev@impala.apache.org
> > 主题: Impala 4.0 breaking changes
> >
> > Now that Impala 3.4 is branched and master is Impala 4.0, we need to
> decide
> > what breaking changes will happen in
> 收件人: dev@impala.apache.org
> 主题: Re: Impala 4.0 breaking changes
>
> I agree. I don’t know how far we are from having arm64 support, though, and
> we might not get there for a 4.0 release, I’d guess. But that doesn’t mean
> it couldn’t arrive by the time for 4.1 or 4.7 or 5.55 or
^
>>
>>
>> 发件人: Jim Apple
>> 发送时间: 2020年3月19日 10:21
>> 收件人: dev@impala.apache.org
>> 主题: Re: Impala 4.0 breaking changes
>>
>> I agree. I don’t know how far we are from having arm64 support, though,
>> and
>>
wrote:
> >
> >> Thanks
> >> I will work hard on this ^_^
> >>
> >>
> >> 发件人: Jim Apple
> >> 发送时间: 2020年3月19日 10:21
> >> 收件人: dev@impala.apache.org
> >> 主题: Re: Impala 4.0 breaking changes
>
; > Any objections or thoughts on these?
> >
> > On Thu, Mar 19, 2020 at 4:44 PM Tim Armstrong
> > wrote:
> >
> > > I think ARM support can ship in whatever release it's reading in, since
> > > it's not a breaking change.
> > >
>
>
> > > Any objections or thoughts on these?
> > >
> > > On Thu, Mar 19, 2020 at 4:44 PM Tim Armstrong >
> > > wrote:
> > >
> > > > I think ARM support can ship in whatever release it's reading in,
> since
> > > >
gt; > > by default, but there can be perf/scalability consequences.
> > > >
> > > > Any objections or thoughts on these?
> > > >
> > > > On Thu, Mar 19, 2020 at 4:44 PM Tim Armstrong <
> tarmstr...@cloudera.com
> > >
> > > > w
gt; > > > >
> > > >
> > >
> >
> https://impala.apache.org/docs/build/html/topics/impala_default_transactional_type.html
> > > > > .
> > > > > The pros and cons here are more complex - we get more consistent
> > > > beh
ps://impala.apache.org/docs/build/html/topics/impala_default_file_format.html
> > > > > >
> > > > > > We could also consider creating insert_only transactional tables
> by
> > > > > default
> > > > > > -
> > > > > >
ssues with escaping)
> > and
> > > > > > because
> > > > > > > it's more performant.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
&
Hi
Could we add support for arm64?
Thanks
Zhao Renhai
发件人: Joe McDonnell
发送时间: 2020年3月17日 1:07
收件人: dev@impala.apache.org
主题: Impala 4.0 breaking changes
Now that Impala 3.4 is branched and master is Impala 4.0, we need to decide
what breaking changes will
Thanks
I will work hard on this ^_^
发件人: Jim Apple
发送时间: 2020年3月19日 10:21
收件人: dev@impala.apache.org
主题: Re: Impala 4.0 breaking changes
I agree. I don’t know how far we are from having arm64 support, though, and
we might not get there for a 4.0 release, I’d
24 matches
Mail list logo
