[Enhancement] in null/not having null supports normalized to value range

[trueeyu]

Why I'm doing:

Currently, only the following pred can be normalized:

• ColumnRef is null
• ColumnRef is no null
• ColumnRef >, >=, <, <=, = const value
• ColumnRef in const values
• ColumnRef not in const values
• The above are combined by or, and

The [ColumnRef in (xxx, yyy, zzz)] is null is not support to be normalized, so the null in in pred or not in pred can be eliminated.

in (xxx, yyy, zzz, null) can be converted to in (xxx, yyy, zzz)
not in (xxx, yyy, zzz, null) can be converted to not in (null), and then convert to empty range.

Finally the in pred with null can be used to filter with zonemap or other index.

Before the pr:

mysql> select count(*) from lineorder_nullable_1_tablet_large where lo_orderkey in (1, 2, null);
+----------+
| count(*) |
+----------+
|        4 |
+----------+
1 row in set (0.64 sec)

mysql> select count(*) from lineorder_nullable_1_tablet_large where lo_orderkey not in (1, 2, null);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.59 sec)

After the pr

mysql> select count(*) from lineorder_nullable_1_tablet_large where lo_orderkey in (1, 2, null);
+----------+
| count(*) |
+----------+
|        4 |
+----------+
1 row in set (0.06 sec)

mysql> select count(*) from lineorder_nullable_1_tablet_large where lo_orderkey not in (1, 2, null);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.02 sec)

What I'm doing:

in null/not in null supports normalized to value range

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.4
  • 3.3
  • 3.2
  • 3.1
  • 3.0

[github-actions]

[Java-Extensions Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[FE Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[kevincai]

what's the difference between clear() and clear_to_empty()?

[trueeyu]

clear_to_empty means all values is filtered,EOF. but clear means to init state, is full range.

[github-actions]

[BE Incremental Coverage Report]

❌ fail : 29 / 39 (74.36%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	be/src/exec/olap_scan_prepare.cpp	15	25	60.00%	[396, 479, 483, 484, 485, 488, 489, 511, 512, 802]
🔵	be/src/exec/olap_common.cpp	9	9	100.00%	[]
🔵	be/src/exprs/in_const_predicate.hpp	1	1	100.00%	[]
🔵	be/src/testutil/schema_test_helper.cpp	4	4	100.00%	[]