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-4252: Min-max runtime filters for Kudu
Date Mon, 23 Oct 2017 22:32:15 GMT
Tim Armstrong has posted comments on this change. ( )

Change subject: IMPALA-4252: Min-max runtime filters for Kudu

Patch Set 6:


Few more comments following on from the previous one. I think my primary concern now is whether
we have enough test coverage of edge cases (low memory, extreme values, etc). The code now
seems solid so mainly concerned about preventing future regressions.
Commit Message:
PS7, Line 26: - Updated planner tests.
Might be worth mentioning why the runtime filters were renumbered in all the planner tests
File be/src/exec/filter-context.h:
PS7, Line 106:   bool bloom_filter() const { return filter->filter_desc().bloom_filter;
Long lines
File be/src/util/min-max-filter.h:
PS7, Line 140:   static void Or(const TMinMaxFilter& in, TMinMaxFilter* out);
Nit: not sure why this is using underscores while AlwaysTrue() is using camel case.

To me it feels like virtual functions should be camel case.
PS7, Line 176:  private:
Can you briefly mention what it means when these are empty - that the values haven't been
File be/src/util/
PS6, Line 291:       BigIntMinMaxFilter::Or(in, out);
> TColumnData doesn't have a timestamp field, so I convert timestamps with Ut
Oh ok, thanks for clarifying. It looked superficially like a last line copy/paste error (

The microseconds unix time does have lower precision than Impala's internal timestamp and
I'm not sure if it has the same range. It may not affect correctness but it's a little tricky
to reason about all the possible cases. It seems like it would be better to keep full precision
until we have to push it to kudu - maybe we could extend TColumnValue to support a native
timestamp type.

Rather confusingly, we have two TColumnValue classes - the HS2 one, which is only used in
a few places, and our internal one. It seems safe to modify our internal one to include a
native timestamp field.

In another place we convert timestamps to string to store in in a TColumnValue - see SetTColumnValue()
in - but it's not totally clear to me why (that code's been there since this
commit in 2012: be98df19c8efe59577e6faaa6089f0383009b703).
File be/src/util/
PS7, Line 137:   if (!in.always_false) {
Do we have end-to-end tests for these code paths? I think we could generally do with some
more targeted tests for edge cases of min/max filters.
PS7, Line 143: rin
static_cast instead of int()?
PS7, Line 143:       out->max.__set_string_val(in.max.string_val);
This has a fairly large number of edge cases - it would be good to unit test it.
PS7, Line 150:   out->min.__set_string_val(in.min.string_val);
I would have expected that we would modify the trailing values that overflowed as well.

i.e. incrementing [0, 255] should give [1, 0]
PS7, Line 207:     case PrimitiveType::TYPE_DOUBLE:
It seems tricky to test these various error paths in end-to-end tests. Could we exercise them
in unit tests?

Maybe also add a brief comment to explain how it's handling the error?

To view, visit
To unsubscribe, visit

Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I02bad890f5b5f78388a3041bf38f89369b5e2f1c
Gerrit-Change-Number: 7793
Gerrit-PatchSet: 6
Gerrit-Owner: Thomas Tauber-Marshall <>
Gerrit-Reviewer: Anonymous Coward #345
Gerrit-Reviewer: Lars Volker <>
Gerrit-Reviewer: Matthew Jacobs <>
Gerrit-Reviewer: Michael Ho <>
Gerrit-Reviewer: Mostafa Mokhtar <>
Gerrit-Reviewer: Thomas Tauber-Marshall <>
Gerrit-Reviewer: Tim Armstrong <>
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-Comment-Date: Mon, 23 Oct 2017 22:32:15 +0000
Gerrit-HasComments: Yes

  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message