Aleksey Plekhanov created IGNITE-16443:
------------------------------------------
Summary: Calcite engine. Incorrect nulls in search row processing
by hash/sorted spools
Key: IGNITE-16443
URL: https://issues.apache.org/jira/browse/IGNITE-16443
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently, the sorted spool comparator treats nulls in the search row as
regular values and applies nulls ordering to them, but these nulls have another
meaning: it means that any value matches the bound.
For example, if we have the condition for spool {{a > 0}} it will be
transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows
with lower bound we will get the correct result, but comparing with upper bound
always give us {{1}} (value > null) with {{nulls first}} collation and no rows
will be returned by index spool.
For hash spool there is the reverse problem, we should not find rows if nulls
are present in the search row, since condition NULL=NULL should not satisfy the
filter in SQL.
Another problem with comparators: there is a dead code in
{{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object by
hash or bytes:
* This code never executes since we support now only comparable types by
Calcite-based SQL engine
* Depends on H2
* Serialize object by standard java serialization
* Works only for ASC ordering
* Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
I think we can get rid of this code at least until we don't support Object
types and revert corresponding changes to ignite-indexing to avoid merge
conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
