statistics: fix repetitive selectivity accounting and stabilify the result (#15536)

[sre-bot]

cherry-pick #15536 to release-2.1

---

What problem does this PR solve?

Problem Summary:

• in Selectivity, index order in coll.Indices is non-deterministic, so the greedy search algorithm may return different results in different runs, that would confuse users since the stats is not changed at all;
• in the greedy search algorithm, there are repetitive selectivity accounting sometimes. For example, if the filter is like t.a = 1 and t.b > 1 and t.c > 1, and there are 2 indexes idx1(a,b) and idx2(a,c), the greedy algorithm would choose both indexes and multiply their selectivity computed respectively. Obviously, this is wrong, because selectivity of t.a = 1 is accounted twice.

What is changed and how it works?

What's Changed:

• do not choose indexes whose filters covered are overlapped;
• sort the StatsNode slice before greedy search;

How it Works:

Note that, how we sort the StatsNode slice impacts the greedy search result. I put the PK in the end of the slice, indexes in the middle and columns in the front, to enforce the heuristic rule that, PK is preferred over indexes in estimation, and indexes are preferred over columns.

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• Unit test

Side effects

• Performance regression: the change of the selectivity result may change plan generated.
• Breaking backward compatibility: nope, in order to keep compatibility, I introduces the compareType function, instead of changing the values of IndexType / PkType / ColType, because feedback encoding uses these constants.

Release note

[sre-bot]

/run-all-tests

[zz-jason]

LGTM

[lzmhhh123]

LGTM

[sre-bot]

Your auto merge job has been accepted, waiting for 16055

[sre-bot]

/run-all-tests