Details
Description
Looks like it is possible to skip the building sorted Ordered_key structures for subselect_rowid_merge_engine when there is only one key in the materialized subquery.
We have predicate
left_expr IN (SELECT <subq1>)
|
where left_expr is a scalar (not a tuple). The logic in this case looks as follows:
if (left_expr is NULL) {
|
if (subq1 produced any rows) {
|
// note that we don't care if subq1 has produced
|
// NULLs or not.
|
NULL IN (<some values>) -> UNKNOWN, i.e. NULL.
|
} else {
|
NULL IN ({empty-set}) -> FALSE.
|
}
|
} else {
|
// left_expr is a non-NULL value
|
if (subq1 output has a match for left_expr) {
|
left_expr IN (..., left_expr ...) -> TRUE
|
} else {
|
// no "known" matches.
|
if (subq1 output has a NULL) {
|
left_expr IN ( ... NULL ...) ->
|
(NULL could have been a match or not)
|
-> NULL.
|
} else {
|
// subq1 didn't produce any "UNKNOWNs" so
|
// we're positive there weren't any matches
|
-> FALSE.
|
}
|
}
|
}
|
Attachments
Issue Links
- relates to
-
MDEV-34041 Additional information for materialized subqueries must be displayed in EXPLAIN/ANALYZE FORMAT=JSON
-
- Closed
-
Activity
Reviewing...
Checking what would subselect_table_scan_engine do when computing
/*col1=*/NULL IN (SELECT ... FROM non_empty_select_without_nulls)
|
It would get into subselect_table_scan_engine::partial_match; would start a table scan and then would find it has a match after reading just one row.
lstartseva, could you please test the branch bb-10.5-MDEV-34665? psergei has already approved the pull request.
Testinп done. Ok to push. But, before pushing it will be better to add some cases for "update" and "delete". This will allow you to check that everything is fine after merging in later versions.
ralf.gebhardt, do you mean this commit won't make it into the upcoming releases? No problem for me to update the version but I don't know where the cut off point is. Who may know it for sure?
psergei, can you please review the PR?