[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--------------------------------------
Description:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('00000000-0000-0001-0000-000000000001'::UUID,
'00000000-0000-0003-0000-000000000001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'00000000-0000-0001-0000-000000000001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'00000000-0000-0003-0000-000000000001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request (#3407).
was:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('00000000-0000-0001-0000-000000000001'::UUID,
'00000000-0000-0003-0000-000000000001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'00000000-0000-0001-0000-000000000001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'00000000-0000-0003-0000-000000000001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request.
> Sql. Index is not used for IN predicate with column type of UUID
> ----------------------------------------------------------------
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Reporter: Konstantin Orlov
> Assignee: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('00000000-0000-0001-0000-000000000001'::UUID,
> '00000000-0000-0003-0000-000000000001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'00000000-0000-0001-0000-000000000001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'00000000-0000-0003-0000-000000000001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h5. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request (#3407).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
