optimizer & runner should consider `NULL` special rules

For a index optimizer, the most common pattern is, for example, SQL `SELECT * FROM t1 WHERE gp = {const_val}`, is optimized based on FILTER expression `gp = {const_val}`:

So if index `key=gp` exists for table t1, that index is utilized, as ** SEEK BY KEY `{const_val}` >> OUTPUT ALL ROWS`**.

However, if `{const_val}` is `NULL`, this optimize rule should not go that approach, since ` = NULL` is `NULL`.

This also happens for SQL like LAST JOIN `t1 LAST JOIN t2 on t1.key = t2.key`, where there is row exists in t1 that `t1.key = NULL`. It never joins.

Optimizer should consider const NULL values, and Runner should consider NULL values as index_key

The issue describes optimizer and runner logic for handling NULL values in index lookups and joins. Look for optimizer code that handles filter expressions like 'gp = {const_val}' and index seek logic. Examine join implementations, particularly LAST JOIN, to see how NULL key equality is currently treated. Testing involves verifying that queries with NULL constants do not incorrectly use indexes and that joins behave correctly with NULL keys.

Escrito por el modelo de indexación a partir del texto del issue.