impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Armstrong (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-4302,IMPALA-2379: constant expr arg fixes
Date Fri, 04 Nov 2016 23:25:13 GMT
Tim Armstrong has posted comments on this change.

Change subject: IMPALA-4302,IMPALA-2379: constant expr arg fixes

Patch Set 4:

Commit Message:

Line 18: arguments for ScalarFnCall expressions on both the codegen'd and
> missing words

PS4, Line 36: temporary
> automatic?  at least I would have understood this a little quicker with tha
File be/src/exprs/

PS4, Line 158: ",
> is it worth differentiating these messages to make debugging easier?
Can't hurt.
File be/src/exprs/anyval-util.h:

PS4, Line 297: The returned AnyVal is not initialized.
> this sentence is repeated
File be/src/exprs/expr-context.h:

PS4, Line 66: fragment
> do you mean fragment instance?
It's kind-of unclear what the direction here is. There's a FRAGMENT_LOCAL concept in the udf
interface that this corresponds to, so I think this is consistent at the moment (although
maybe it should be FRAGMENT_INSTANCE_LOCAL everywhere).
File be/src/exprs/

PS4, Line 188: fragment
> fragment or fragment instance?
Reworded to avoid making the distinction and be clearer. It's not clear that the FRAGMENT_LOCAL
terminology is accurate, but I think that's out of scope for this fix.

PS4, Line 189: cases
> not sure what this sentence is saying. what cases?
Reworded to be clearer. It's copied when the ExprContext is cloned.

Line 205:     // children.
> do we document the calling convention somewhere? I think a brief explanatio
Updated the comment. The UDF calling convention is in udf/udf.h and the contents of the buffers
are in udf/udf-internal.h

PS4, Line 340: optimise out the buffer
> is this also enabling constant propagation for constant args, or was that a
The constant was propagated but the side-effect of storing to the varargs buffer couldn't
be optimised out.

PS4, Line 370: Either no varargs or arguments before varargs begin
> this comment seems unnecessary with the new conditional
File be/src/runtime/free-pool.h:

Line 73:     size = std::max<int64_t>(8, size);
> seems fine, but why is it required?
Not required but it's pointless making smaller allocations, since it's aligned to 8 bytes
by the MemPool anyway. Added a comment

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I45c3ed8c9d7a61e94a9b9d6c316e8a53d9ff6c24
Gerrit-PatchSet: 4
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Tim Armstrong <>
Gerrit-Reviewer: Dan Hecht <>
Gerrit-Reviewer: Michael Ho
Gerrit-Reviewer: Tim Armstrong <>
Gerrit-HasComments: Yes

View raw message