Support Value-based InSource #2717
Assignees
Labels
Comments
alecgrieser
added
enhancement
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
May 15, 2024
This allows for `IN`s with a `Value` based source to be used during query execution with an IN-join or IN-union plan. There already was an `InComparandSource`, so rather than introducing a new one, it makes use of that existing class. This resolves FoundationDB#2717.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
May 15, 2024
This allows for `IN`s with a `Value` based source to be used during query execution with an IN-join or IN-union plan. There already was an `InComparandSource`, so rather than introducing a new one, it makes use of that existing class. This resolves FoundationDB#2717.
normen662
pushed a commit
that referenced
this issue
May 22, 2024
* update IN tests to be dual planner * Resolves #2717: Support Value-based InSource This allows for `IN`s with a `Value` based source to be used during query execution with an IN-join or IN-union plan. There already was an `InComparandSource`, so rather than introducing a new one, it makes use of that existing class. This resolves #2717. * remove planPartition filtering so that InJoin can be used with aggregates * update release note * remove `instanceof ConstantObjectValue` in favor of `.isConstant()`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Within the Cacades planner, there are methods for converting certain
EXPLODEexpressions intoInSources for IN-join and IN-union planning. However, this logic is restricted to onlyLiteralValues (which get turned intoInValuessources) andQuantifiedObjectValues (which get turned intoInParametersources). We're missing a few types, such asConstantObjectValues.We could add a
Value-basedInSourcethat can wrapConstantObjectValues (etc) and then use those. There's a bit of work to consider here, to make sure that we don't use these values where it isn't appropriate. There's also some thought that we'll probably want to replace those with nested-loop joins and merge joins in the future, at which point we can probably remove these types of plans.The text was updated successfully, but these errors were encountered: