Simplify merging enrich output #107018
Merged
Simplify merging enrich output #107018
Conversation
This file contains 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
dnhatn
force-pushed
the
enrich-append-values
branch
5 times, most recently
from
32c385d to
5a012b6
Compare
dnhatn
commented
Apr 2, 2024
| if (cell.length > 1) { | ||
| builder.beginPositionEntry(); | ||
| } | ||
| // TODO: sort and dedup |
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
elasticsearchmachine
added
the
Team:Analytics
dnhatn
commented
Apr 2, 2024
| private final int[] mergingChannels; | ||
| private final ElementType[] mergingTypes; | ||
| private PositionBuilder positionBuilder = null; | ||
| private final EnrichResultBuilder[] builders; |
There was a problem hiding this comment.
This class becomes much simpler.
dnhatn
force-pushed
the
enrich-append-values
branch
from
5a012b6 to
0794d05
Compare
|
@nik9000 I have benchmarked this change, along with two incoming improvements: one for reading values in batch, and another for leveraging the bytesref ordinal block. With these three changes, enrich in our benchmark is 11 times faster: from 330ms to 30ms. |
|
@nik9000 Thanks for reviewing :) |
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
Apr 10, 2024
Landing elastic#107018 broke running ESQL unit tests in IntelliJ. It has *something* to do with turning on the stringtemplate plugin in the esql project but I don't really know what. After that PR we'd often get errors about trying to regenerate evaluators twice. I dunno. This fixes it. But I don't really know why. The way this fixes it is by making the `esql` project more like the `copmute` project. It makes sense that that would help - they both have the same code generation configuration. Anyway, the operative change is landing the generated files in the same place as the `compute` project. Thus all of the file moves. Again, I have no idea why this works. It's build black magic and I just shook it until it worked. Most of the credit goes to git-bisect for finding the commit that broke this.
nik9000
added a commit
that referenced
this pull request
Apr 11, 2024
Landing #107018 broke running ESQL unit tests in IntelliJ. It has *something* to do with turning on the stringtemplate plugin in the esql project but I don't really know what. After that PR we'd often get errors about trying to regenerate evaluators twice. I dunno. This fixes it. But I don't really know why. The way this fixes it is by making the `esql` project more like the `copmute` project. It makes sense that that would help - they both have the same code generation configuration. Anyway, the operative change is landing the generated files in the same place as the `compute` project. Thus all of the file moves. Again, I have no idea why this works. It's build black magic and I just shook it until it worked. Most of the credit goes to git-bisect for finding the commit that broke this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The merge logic in MergePositionsOperator is excessively complex and lacks flexibility. It relies on the source operator emitting pages with ascending positions. Additionally, this merge logic introduced an unusual method,
appendAllValuesToCurrentPosition, to the Block.Builder. We should replace this with a simpler and more flexible approach. This PR uses a mechanism similar to the grouping aggregation. In fact, it is very close to the values aggregation. Initially, I considered using the GroupingState from ValuesAggregator. However, unlike in the values aggregation, we don't expect many multi-values in enrich. Hence, I introduced the new EnrichResultBuilders instead.