-
Notifications
You must be signed in to change notification settings - Fork 550
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize query building for array_length and array_upper #7754
Conversation
} | ||
Number cmpNumber = (Number) ((Input) cmpSymbol).value(); | ||
if (cmpNumber == null) { | ||
// TODO: this case is never reached due to early normalization + no-match detection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we drop this code block then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering if I should add a unit test for this case so that it's hit or replace it with an assertion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, an assertion would be great
private static IntUnaryOperator numValuesPerDocForBoolean(LeafReader reader, ColumnIdent column) { | ||
SortedBinaryDocValues docValues; | ||
try { | ||
docValues = FieldData.toString(DocValues.getSortedNumeric(reader, column.fqn())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't it irrelevant to wrap it into toString
as long as we are only interested in the value count?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, awesome improvement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great, lgtm.
Various cases will be optimized, so they'll end up using different Lucene queries which is why we should test all different cases.
cfec665
to
b546d9e
Compare
b546d9e
to
78d3221
Compare
78d3221
to
f6499ac
Compare
CHANGES.txt