MDEV-34665 Simplify IN predicate processing for NULL-aware materializ…

[Olernov]

trafficstars

…ation involving only one column

• [x] *The Jira issue number for this PR is: MDEV-34665

It was found that unnecessary work of building Ordered_key structures is being done when processing NULL-aware materialization for IN predicates having only one column. In fact, the logic for that simplified case can be expressed as follows. Say we have predicate left_expr IN (SELECT <subq1>), where left_expr is scalar(not a tuple). Then

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.
     }
   }
 }

This commit introduces subselect_single_column_partial_engine class implementing the logic described.

Release Notes

TODO: What should the release notes say about this change? Include any changed system variables, status variables or behaviour. Optionally list any https://mariadb.com/kb/ pages that need changing.

How can this PR be tested?

TODO: modify the automated test suite to verify that the PR causes MariaDB to behave as intended. Consult the documentation on "Writing good test cases".

If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.

Basing the PR against the correct MariaDB version

• [ ] This is a new feature or a refactoring, and the PR is based against the latest MariaDB development branch.
• [x] This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• [x] I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• [x] For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.