MDEV-36094 Row ID filtering for reverse-ordered scans

[DaveGosselin-MariaDB]

This PR has two commits:

Second commit:

The fix for MDEV-34413 added support for Index Condition Pushdown with reverse ordered scans. This makes Rowid filtering work with reverse-ordered scans, too, so enable it. For example, InnoDB can now check the pushed index condition and then check the rowid filter on success, in the ORDER BY ... DESC case.

First commit:

Add tests showing that RowID filtering is not enabled for reverse-ordered scans.

[spetrunia]

The patch adds Handler_rowid_filter_attempts and ...matches counters. Is there any problem with looking at ANALYZE FORMAT=JSON output, instead?

I'm wondering if these counters would make sense for the end-users (i.e. non-database devs). Globals like "[index] rows read" seem to make sense, but I have a doubt whether global "rowid filter checks" is useful.

[DaveGosselin-MariaDB]

The patch adds Handler_rowid_filter_attempts and ...matches counters. Is there any problem with looking at ANALYZE FORMAT=JSON output, instead?

I'm wondering if these counters would make sense for the end-users (i.e. non-database devs). Globals like "[index] rows read" seem to make sense, but I have a doubt whether global "rowid filter checks" is useful.

I'm not sure what you mean by "The patch adds Handler_rowid_filter_attempts and ...matches counters"; to clarify, the first commit shows that the new counters are zero, then the second shows that they're nonzero, reflecting that the changes to enable rowid filtering for reverse scans is in effect.

I'm happy to remove the counters and look at analyze format=json output using json_extract instead, especially if you think that the counters are not useful. I don't want to add something that you think isn't needed. 😊

[spetrunia]

Need attion on the above comments.

[spetrunia]

Note that a few lines above, on line 3755, there is a note:

# The following must NOT use Rowid Filter:

It needs to be updated.

[spetrunia]

Doesn't this show that the Rowid Filter with ICP has the "walk-off-the-end-of-range" problem?

r_index_rows=5251. This is 20x what the server expected (rows=250).

Just to be sure, I've added to the test the same query with ORDER BY ASC. The output is:
https://gist.github.com/spetrunia/7ae335d01775400bb607672111c202ab

Key place:

          "rowid_filter": {
            "range": {
              "key": "b",
              "used_key_parts": ["b"]
            },
            "rows": 252,
            "selectivity_pct": 4.799085888,
            "r_rows": 250,
            "r_lookups": 250,
            "r_selectivity_pct": 100,
            "r_buffer_size": "REPLACED",
            "r_filling_time_ms": "REPLACED"
          },
          "loops": 1,
          "r_loops": 1,
          "rows": 250,
          "r_index_rows": 250,
          "r_rows": 250,

note r_index_rows=rows= 250, note r_lookups=250.
This is how it should have worked.

Please investigate this.