-
Notifications
You must be signed in to change notification settings - Fork 25.3k
ESQL: Compute infrastruture for LEFT JOIN #118889
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
Conversation
This adds some infrastructure that we can use to run LOOKUP JOIN using real LEFT JOIN semantics. Right now if LOOKUP JOIN matches many rows in the `lookup` index we merge all of the values into a multivalued field. So the number of rows emitted from LOOKUP JOIN is the same as the number of rows that comes into LOOKUP JOIN. This change builds the infrastructure to emit one row per match, mostly reusing the infrastructure from ENRICH.
Pinging @elastic/es-analytical-engine (Team:Analytics) |
I'd like to add another randomized test to this and then get it in. Then I'd like to plug it in in a follow up change. That change will:
|
x-pack/plugin/esql/compute/src/main/java/org/elasticsearch/compute/data/Block.java
Outdated
Show resolved
Hide resolved
* | l99 | null | null | | ||
* }</pre> | ||
*/ | ||
class RightChunkedLeftJoin implements Releasable { |
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.
👍 for the asciiart
...ql/compute/src/main/java/org/elasticsearch/compute/operator/lookup/RightChunkedLeftJoin.java
Show resolved
Hide resolved
try { | ||
int b = 0; | ||
while (b < leftHand.getBlockCount()) { | ||
blocks[b] = leftHand.getBlock(b).filter(filter); |
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.
Nit:
To avoid allocating the array, a new method could be added to block for consecutive integers such as Block#filter(int start, int stop)
or depending how well it gets JITed a Range class Block#filter(range)
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. There's a lot we could do here to be honest. The range version of filter might be quite nice.
I think those might be for a follow up.
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
I've pushed a randomize test that seems to fail .7% of the time. Fun. I'll have a debug when I'm back. |
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!
...esql/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/LookupFromIndexIT.java
Outdated
Show resolved
Hide resolved
...esql/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/LookupFromIndexIT.java
Show resolved
Hide resolved
void populate(int docCount, List<String> expected) throws IOException; | ||
} | ||
|
||
private void runLookup(PopulateIndices populateIndices) throws IOException { | ||
// TODO this should *fail* if the target index isn't a lookup type index - it doesn't now. |
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.
Unrelated: If this comment talks about the ESQL query, it does fail now
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. That was about the query. Great news!
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.
We build multiple vectors/blocks here. Should we add a cranky CB test?
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.
Yes.
Looks like I never backported this... bleh. Incoming |
This adds some infrastructure that we can use to run LOOKUP JOIN using real LEFT JOIN semantics. Right now if LOOKUP JOIN matches many rows in the `lookup` index we merge all of the values into a multivalued field. So the number of rows emitted from LOOKUP JOIN is the same as the number of rows that comes into LOOKUP JOIN. This change builds the infrastructure to emit one row per match, mostly reusing the infrastructure from ENRICH.
backport is #120232 |
* ESQL: Compute infrastruture for LEFT JOIN (#118889) This adds some infrastructure that we can use to run LOOKUP JOIN using real LEFT JOIN semantics. Right now if LOOKUP JOIN matches many rows in the `lookup` index we merge all of the values into a multivalued field. So the number of rows emitted from LOOKUP JOIN is the same as the number of rows that comes into LOOKUP JOIN. This change builds the infrastructure to emit one row per match, mostly reusing the infrastructure from ENRICH. * ESQL: Make LOOKUP more left-joiny (#119475) This makes `LOOKUP` return multiple rows if there are multiple matches. This is the way SQL works so it's *probably* what folks will expect. Even if it isn't, it allows for more optimizations. Like, this change doesn't optimize anything - it just changes the behavior. But there are optimizations you can do *later* that are transparent when we have *this* behavior, but not with the old behavior. Example: ``` - 2 | [German, German, German] | [Austria, Germany, Switzerland] + 2 | German | [Austria, Germany] + 2 | German | Switzerland + 2 | German | null ``` Relates: #118781
This adds some infrastructure that we can use to run LOOKUP JOIN using real LEFT JOIN semantics.
Right now if LOOKUP JOIN matches many rows in the
lookup
index we merge all of the values into a multivalued field. So the number of rows emitted from LOOKUP JOIN is the same as the number of rows that comes into LOOKUP JOIN.This change builds the infrastructure to emit one row per match, mostly reusing the infrastructure from ENRICH.