Skip to content
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

BytesRefOrdValComparator ignores highest value in a segment during binarySearch #2991

Closed
s1monw opened this Issue May 4, 2013 · 0 comments

Comments

Projects
None yet
1 participant
@s1monw
Copy link
Contributor

s1monw commented May 4, 2013

The BytesRefOrdValComparator uses Ordinals.Docs.getNumOrdinals() -1 as the upperbound for the binarysearch. The -1 causes that we ignore the last value in the segment.

This is kind of a very tricky bug since it only happens if we need to binary-search to align ords and the bottom of the sort queue is greater than the largest value in the segment but less than the second largest. This was causing an issue reported by a user on the mailing list: https://groups.google.com/d/msg/elasticsearch/W5s1KypYcYw/L1UgixO_gQ4J

@ghost ghost assigned s1monw May 4, 2013

@s1monw s1monw closed this in 29da615 May 6, 2013

s1monw added a commit that referenced this issue May 6, 2013

Use full ord range in binary search. The upperbound of the binary sea…
…rch in

BytesRefOrdValComparator starts at 1 and ends at maxOrd - 1. Yet, numOrd is defined
as maxOrd - 1 excluding the 0 ord.

This causes wrong sort ords when the bottom of the queue is compared to the next
segment and the greatest term in the new segment is in-fact less than the current
queue bottom. If that is true we treat the values as equal and never include the right
value into the queue.

Closes #2991

mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015

Use full ord range in binary search. The upperbound of the binary sea…
…rch in

BytesRefOrdValComparator starts at 1 and ends at maxOrd - 1. Yet, numOrd is defined
as maxOrd - 1 excluding the 0 ord.

This causes wrong sort ords when the bottom of the queue is compared to the next
segment and the greatest term in the new segment is in-fact less than the current
queue bottom. If that is true we treat the values as equal and never include the right
value into the queue.

Closes elastic#2991
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.