Create new block when filter OrdinalBytesRefBlock#136444
Merged
dnhatn merged 5 commits intoelastic:mainfrom Oct 15, 2025
Merged
Create new block when filter OrdinalBytesRefBlock#136444dnhatn merged 5 commits intoelastic:mainfrom
dnhatn merged 5 commits intoelastic:mainfrom
Conversation
dnhatn
added
:Analytics/ES|QL
elasticsearchmachine
added
the
Team:Analytics
Collaborator
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Collaborator
|
Hi @dnhatn, I've created a changelog YAML for you. |
dnhatn
commented
Oct 11, 2025
| 15 | Senior Team Lead | ||
| 11 | Support Engineer | ||
| 15 | Tech Lead | ||
| ; |
Member
Author
There was a problem hiding this comment.
Without the fix, Purchase Manager would re-appear in the result.
employees:long | job_positions:keyword
18 | Accountant
13 | Architect
11 | Business Analyst
13 | Data Scientist
10 | Head Human Resources
15 | Internship
14 | Junior Developer
20 | Principal Support Engineer
0 | Purchase Manager
13 | Python Developer
15 | Reporting Analyst
20 | Senior Python Developer
15 | Senior Team Lead
11 | Support Engineer
15 | Tech Lead
nik9000
approved these changes
Oct 15, 2025
Member
|
Oh that one's exciting! |
Member
Author
|
Thanks Nik! |
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
dnhatn
added a commit
to dnhatn/elasticsearch
that referenced
this pull request
Oct 15, 2025
Currently, when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector, we reuse the existing dictionary and filter only the ordinals. Although this is semantically correct, it can break HashAggregationOperator when ordinal optimizations are enabled in BlockHash. Example: given an incoming OrdinalBytesRefBlock after filtering: dict: [apple, banana, orange] ordinals: [0, 0, 0, 0, 1, 1] Here, orange is not referenced. During grouping and hashing, all dictionary entries [apple, banana, orange] are hashed with group IDs [1, 2, 3] (0 reserved for null), and the block produces groupings [1, 1, 1, 1, 2, 2]. The output is correct, but when evaluating partial/final results, we cannot exclude orange (groupId=3) unless we enter slow mode and track every seen group. This can cause an IndexOutOfBoundsException if orange is the largest group and the over-allocation is not enough to cover it, or orange may be included in the result even though it was excluded previously. This change enforces the creation of a new Block/Vector when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector. Closes elastic#136423
elasticsearchmachine
pushed a commit
that referenced
this pull request
Oct 15, 2025
Currently, when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector, we reuse the existing dictionary and filter only the ordinals. Although this is semantically correct, it can break HashAggregationOperator when ordinal optimizations are enabled in BlockHash. Example: given an incoming OrdinalBytesRefBlock after filtering: dict: [apple, banana, orange] ordinals: [0, 0, 0, 0, 1, 1] Here, orange is not referenced. During grouping and hashing, all dictionary entries [apple, banana, orange] are hashed with group IDs [1, 2, 3] (0 reserved for null), and the block produces groupings [1, 1, 1, 1, 2, 2]. The output is correct, but when evaluating partial/final results, we cannot exclude orange (groupId=3) unless we enter slow mode and track every seen group. This can cause an IndexOutOfBoundsException if orange is the largest group and the over-allocation is not enough to cover it, or orange may be included in the result even though it was excluded previously. This change enforces the creation of a new Block/Vector when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector. Closes #136423
Kubik42
pushed a commit
to Kubik42/elasticsearch
that referenced
this pull request
Oct 16, 2025
Currently, when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector, we reuse the existing dictionary and filter only the ordinals. Although this is semantically correct, it can break HashAggregationOperator when ordinal optimizations are enabled in BlockHash. Example: given an incoming OrdinalBytesRefBlock after filtering: dict: [apple, banana, orange] ordinals: [0, 0, 0, 0, 1, 1] Here, orange is not referenced. During grouping and hashing, all dictionary entries [apple, banana, orange] are hashed with group IDs [1, 2, 3] (0 reserved for null), and the block produces groupings [1, 1, 1, 1, 2, 2]. The output is correct, but when evaluating partial/final results, we cannot exclude orange (groupId=3) unless we enter slow mode and track every seen group. This can cause an IndexOutOfBoundsException if orange is the largest group and the over-allocation is not enough to cover it, or orange may be included in the result even though it was excluded previously. This change enforces the creation of a new Block/Vector when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector. Closes elastic#136423
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector, we reuse the existing dictionary and filter only the ordinals. Although this is semantically correct, it can break HashAggregationOperator when ordinal optimizations are enabled in BlockHash.
Example: given an incoming OrdinalBytesRefBlock after filtering:
Here,
orangeis not referenced. During grouping and hashing, all dictionary entries [apple,banana,orange] are hashed with group IDs [1, 2, 3] (0 reserved for null), and the block produces groupings [1, 1, 1, 1, 2, 2]. The output is correct, but when evaluating partial/final results, we cannot excludeorange(groupId=3) unless we enter slow mode and track every seen group. This can cause an IndexOutOfBoundsException iforangeis the largest group and the over-allocation is not enough to cover it, ororangemay be included in the result even though it was excluded previously.This change enforces the creation of a new Block/Vector when filtering OrdinalBytesRefBlock and OrdinalBytesRefVector.
Closes #136423