ESQL: TO_LOWER process all values #124676
Merged
Conversation
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
Make `TO_LOWER` and `TO_UPPER` process all values it received. This is quite large because it borrows a lot of code from the regular evaluator generator to generate conversions so we can use the Locale. That change propagates to the order of some parameters and to the `toString` and a few more places. Closes elastic#124002
elasticsearchmachine
added
the
Team:Analytics
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
|
Hi @nik9000, I've created a changelog YAML for you. |
nik9000
changed the title
|
I believe this one doesn't require anything else around push down - we push down TO_LOWER0-ed comparisons to lucene. All of those comparisons need single valued fields though. I'm going to have a look at how that's done to much sure there's nothing to do. |
|
Looks like the PR that enabled push down is #118870. |
|
This doesn't really change the benchmarks: Well, it does, but it's pretty within the error. |
|
I double checked push down and it all looks good. The equality still neesd single values. |
jfreden
pushed a commit
to jfreden/elasticsearch
that referenced
this pull request
Mar 13, 2025
Make `TO_LOWER` and `TO_UPPER` process all values it received. This is quite large because it borrows a lot of code from the regular evaluator generator to generate conversions so we can use the Locale. That change propagates to the order of some parameters and to the `toString` and a few more places. Closes elastic#124002
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
Apr 7, 2025
Speed up the TO_IP method by converting directly from utf-8 encoded strings to the ip encoding. Previously we did: ``` utf-8 -> String -> INetAddress -> ip encoding ``` In a step towards solving elastic#125460 this creates three IP parsing functions, one the rejects leading zeros, one that interprets leading zeros as decimal numbers, and one the interprets leading zeros as octal numbers. IPs have historically been parsed in all three of those ways. This plugs the "rejects leading zeros" parser into `TO_IP` because that's the behavior it had before. Here is the performance: ``` Benchmark Score Error Units leadingZerosAreDecimal 14.007 ± 0.093 ns/op leadingZerosAreOctal 15.020 ± 0.373 ns/op leadingZerosRejected 14.176 ± 3.861 ns/op original 32.950 ± 1.062 ns/op ``` So this is roughly 45% faster than what we had. This includes a big chunk of elastic#124676 - but not the behavior change - just the code that allowed it.
This was referenced Apr 7, 2025
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
Apr 7, 2025
Speed up the TO_IP method by converting directly from utf-8 encoded strings to the ip encoding. Previously we did: ``` utf-8 -> String -> INetAddress -> ip encoding ``` In a step towards solving elastic#125460 this creates three IP parsing functions, one the rejects leading zeros, one that interprets leading zeros as decimal numbers, and one the interprets leading zeros as octal numbers. IPs have historically been parsed in all three of those ways. This plugs the "rejects leading zeros" parser into `TO_IP` because that's the behavior it had before. Here is the performance: ``` Benchmark Score Error Units leadingZerosAreDecimal 14.007 ± 0.093 ns/op leadingZerosAreOctal 15.020 ± 0.373 ns/op leadingZerosRejected 14.176 ± 3.861 ns/op original 32.950 ± 1.062 ns/op ``` So this is roughly 45% faster than what we had. This includes a big chunk of elastic#124676 - but not the behavior change - just the code that allowed it.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Apr 7, 2025
Speed up the TO_IP method by converting directly from utf-8 encoded strings to the ip encoding. Previously we did: ``` utf-8 -> String -> INetAddress -> ip encoding ``` In a step towards solving #125460 this creates three IP parsing functions, one the rejects leading zeros, one that interprets leading zeros as decimal numbers, and one the interprets leading zeros as octal numbers. IPs have historically been parsed in all three of those ways. This plugs the "rejects leading zeros" parser into `TO_IP` because that's the behavior it had before. Here is the performance: ``` Benchmark Score Error Units leadingZerosAreDecimal 14.007 ± 0.093 ns/op leadingZerosAreOctal 15.020 ± 0.373 ns/op leadingZerosRejected 14.176 ± 3.861 ns/op original 32.950 ± 1.062 ns/op ``` So this is roughly 45% faster than what we had. This includes a big chunk of #124676 - but not the behavior change - just the code that allowed it.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Apr 7, 2025
Speed up the TO_IP method by converting directly from utf-8 encoded strings to the ip encoding. Previously we did: ``` utf-8 -> String -> INetAddress -> ip encoding ``` In a step towards solving #125460 this creates three IP parsing functions, one the rejects leading zeros, one that interprets leading zeros as decimal numbers, and one the interprets leading zeros as octal numbers. IPs have historically been parsed in all three of those ways. This plugs the "rejects leading zeros" parser into `TO_IP` because that's the behavior it had before. Here is the performance: ``` Benchmark Score Error Units leadingZerosAreDecimal 14.007 ± 0.093 ns/op leadingZerosAreOctal 15.020 ± 0.373 ns/op leadingZerosRejected 14.176 ± 3.861 ns/op original 32.950 ± 1.062 ns/op ``` So this is roughly 45% faster than what we had. This includes a big chunk of #124676 - but not the behavior change - just the code that allowed it.
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
May 6, 2025
Make `TO_LOWER` and `TO_UPPER` process all values it received. This is quite large because it borrows a lot of code from the regular evaluator generator to generate conversions so we can use the Locale. That change propagates to the order of some parameters and to the `toString` and a few more places. Closes elastic#124002
elasticsearchmachine
pushed a commit
that referenced
this pull request
May 8, 2025
Make `TO_LOWER` and `TO_UPPER` process all values it received. This is quite large because it borrows a lot of code from the regular evaluator generator to generate conversions so we can use the Locale. That change propagates to the order of some parameters and to the `toString` and a few more places. Closes #124002
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.
Make
TO_LOWERandTO_UPPERprocess all values it receives.This is quite large because it borrows a lot of code from the regular evaluator generator to generate conversions so we can use the Locale. That change propagates to the order of some parameters and to the
toStringand a few more places.Closes #124002