roject.
>
> I think the main workaround would be to use a different Kudu client to
> directly drop the tables. AFAIK the intent of external Kudu tables was
> generally that they would be dropped externally to Impala - I don't think
> we anticipated the "attach then drop"
oh nowhy?? just why?? we are about to upgrade to 2.12...
Todd, can this "improvement" get rolled back? This a breaking change and
does not contribute to making anything better. And now the only good way to
swap Kudu tables is gone.
I am really frustrated. IMPALA-5654
interesting post by Adir Mashiach
https://medium.com/@adirmashiach/5-main-missing-features-in-impala-imo-1343c767081f
We just started our journey with Impala on HDFS and Impala on Kudu and we
have mixed feelings too. While it is awesome and fast, we already hit 4
major issues during upgrades and
Hey guys,
we've reviewed the docs but still not sure why query 1 works fine and query
2 errors out with a syntax error. The only difference is that I have Hash
partition first and then a Range.
ERROR: AnalysisException: Syntax error in line 13:
),
^
Encountered: COMMA
Expected: AS,
ber of HASH() clauses followed
>> by exactly zero
>> // or one RANGE clauses
>>
>> Is it mentioned somewhere in the docs that this can be done the other way
>> around?
>> Note, I'm not sure which Impala version you use, I took cdh5-trunk to do
>> this resear
Hello,
How can I see in Impala that partition pruning happening with Kudu tables?
When I do an EXPLAIN plan on my query or see profile, I do not see anything
that would indicate that Impala filtered partitions.
With Impala on HDFS, I can clearly see if only a few partitions were used.
For
Hello and Happy Friday!
We decided to store date/timestamps as a string due to all the issues we
had with time zones and the way we want them to work consistently across
Impala, Hive, Kudu and Spark.
In a query like below, I thought I would have to convert strings with
timestamps to timestamp
CTEs with >1 reference to them do so via
> temporary tables behind the scenes. That said, such functionality does not
> exist in Impala today, but there is a JIRA for it:
> https://issues.apache.org/jira/browse/IMPALA-8083
>
>
>
> On Thu, Jun 27, 2019 at 9:50 AM Boris Tyuk
ion) so this would require
> a significant amount of planner work
>
> -Andrew
>
> On Tue, Oct 15, 2019 at 7:47 AM Boris Tyukin
> wrote:
>
>> Hi guys,
>>
>> I am curious if there are any discussions regarding the support of a
>> query rewrite feature in I
Did you try to remove limit clause? It seems from a plan that limit is
applied during exchange
On Fri, Nov 1, 2019, 00:00 Dinushka wrote:
> Hi,
>
> Thank you very much for the advice. I have attached the profile logs. Each
> table is have 160 columns. each will only return one row and only
>
they did a pretty good job explaining why Kudu was born in the docs
https://kudu.apache.org/docs/
and there are tons of posts on the subject including my post
https://boristyukin.com/benchmarking-apache-kudu-vs-apache-impala/
Mainly, Kudu allows to have mutable data and faster seeks. So if your
Jeff, I think your best option is to use ilike/iregexp. One of these things
that I do not like about Impala :)
bonus tip, if you end up with lots of LIKEs, regexp will be way more
efficient.
In CDH 5.7 / Impala 2.5 and higher, you can simplify queries that use many
UPPER() and LOWER() calls to
12 matches
Mail list logo
