[mariadb-YuchenPei]

The idea of Case 2 in can_skip_merging_scans is that when partition column key prefix is fixed, and the infix that is also the "partition by range" column, we can scan each partition in order. This relies on accurately returning EOF when a partition has no (more) matching rows. It is possible to have no more matching rows at the first index read of a partition in a non-exact access, in which case we need to check the prefix match to rule out false positives and return EOF correctly.

This change by itself would result in incomplete results, if Case 2 incorrectly determines the scan can iterate over partitions in order in AFTER_KEY and BEFORE_KEY reads. These reads when applied to a partition column key prefix, necessarily means seeking a different prefix value. This could result in false negatives. To that end, we strengthen the checks in Case 2 so that AFTER_KEY and BEFORE_KEY reads require both the prefix and the partitioned column itself in the keypart_map to ensure correctness.

For example, this check disqualifies the index_read_map call in an existing loose index scan testcase, causing the index scan to use both unordered (in read_range_first) and ordered.

Since we have to enumerate all flags, we include a fix of missing reverse_order for KEY_OR_PREV. The only known usecase is HANDLER ... READ which is not working correctly and due to be fixed in MDEV-41364. For consistency with other equally incorrect HANDLER cases involving other flags, we do not single out KEY_OR_PREV for special treatment (e.g. return false in can_skip_merging_scans).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}