What you've found in the code is correctly. There are currently a few
places where we do not
take advantage of codegen. None of them are architectural
or fundamental limitations, we simply
have not had time to implement those paths. In the upcoming releases, we
will implement more
of this.

As a general rule, codegen is enabled on a (exec) node by node. If any of
the exprs in the node
does not yet support codegen, the entire node uses the interpreted path.
We've prioritized
implementing paths where codegen will be most beneficial. For example,
unescaping strings
will be dominated by the operation itself; not the interpretation overhead.

Hope that helps,

On Sun, Mar 31, 2013 at 8:41 PM, wrote:

Hi all:
In recent days, I worked in impala.
I doubted in which situtations, impala don't generate llvm code.

I look over the source code, found:
1. in aggregation, materialized field contains TIMESTAMP type or STRING
type (exec/hdfs-scanner.cc)
2. in conjunct operation is one of exprs can not generate llvm code
3. in hash_table, one of build_exprs or probe_exprs can not generate
llvm code
4. In generate ProcessRowBatch llvm code can not generate code if in
which one of tuples/slots can not generate code
5. in field string need to escape (in text-convert.h)

I'm pretty puzzled right now. Which situations or the principles impala
can not gen llvm code?

Best regard.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupimpala-user @
postedApr 1, '13 at 6:28p
activeApr 1, '13 at 6:28p

1 user in discussion

Nong Li: 1 post



site design / logo © 2022 Grokbase