[
https://issues.apache.org/jira/browse/IGNITE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17655:
--------------------------------------
Description:
After IGNITE-17431 indexes became a part of query plan. So, now we need to
provide appropriate runtime to make an execution of index scans possible.
Integration points for sql engine will be interface
org.apache.ignite.internal.index.Index and derived
org.apache.ignite.internal.index.SortedIndex. A few changes is required to
those interfaces though: the {{scan}} methods should be reworked in the
following way:
{code:java}
// for Index.java scan should look like this one
Publisher<BinaryTuple> scan(int partId, InternalTransaction tx, BinaryTuple
key, BitSet columnsToInclude)
// for SortedIndex.java range scan should look like this
Publisher<BinaryTuple> scan(int partId, InternalTransaction tx, @Nullable
BinaryTuple leftBound, @Nullable BinaryTuple rightBound, int flags, BitSet
columnsToInclude)
{code}
Besides, we need to reconsider the way we work with an index conditions.
Currently we stick with Ignite-2 way, where search row is represented by a
tuple of the same size as table row, but only indexed columns is set to a
particular values while others are set to null. For example for table (id,
project_id, command_id, name) and index (command_id, project_id) a search tuple
looks like (null, <project_id_condition>, <command_id_condition>, null). We
need to rework this in a way to make a search tuple match the actual order of
indexed columns. With that said, the search tuple for the example above should
look like (<command_id_condition>, <project_id_condition>).
Finally, since both table and index scan have the very similar API, it seems
reasonable to rework
{{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
cover both cases (table scan and index scan).
was:
After IGNITE-17431 indexes became a part of query plan. So, now we need to
provide appropriate runtime to make an execution of index scans possible.
Integration points for sql engine will be interface
org.apache.ignite.internal.index.Index and derived
org.apache.ignite.internal.index.SortedIndex. A few changes is required to
those interfaces though: the {{scan}} methods should be reworked in the
following way:
{code:java}
// for Index.java scan should look like this one
Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple key, BitSet columnsToInclude)
// for SortedIndex.java range scan should look like this
Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx,
BinaryTuple leftBound, BinaryTuple rightBound, int flags, BitSet
columnsToInclude)
{code}
Besides, we need to reconsider the way we work with an index conditions.
Currently we stick with Ignite-2 way, where search row is represented by a
tuple of the same size as table row, but only indexed columns is set to a
particular values while others are set to null. For example for table (id,
project_id, command_id, name) and index (command_id, project_id) a search tuple
looks like (null, <project_id_condition>, <command_id_condition>, null). We
need to rework this in a way to make a search tuple match the actual order of
indexed columns. With that said, the search tuple for the example above should
look like (<command_id_condition>, <project_id_condition>).
Finally, since both table and index scan have the very similar API, it seems
reasonable to rework
{{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
cover both cases (table scan and index scan).
> Sql. Provide integration for index scan
> ---------------------------------------
>
> Key: IGNITE-17655
> URL: https://issues.apache.org/jira/browse/IGNITE-17655
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Konstantin Orlov
> Priority: Major
> Labels: ignite-3
>
> After IGNITE-17431 indexes became a part of query plan. So, now we need to
> provide appropriate runtime to make an execution of index scans possible.
> Integration points for sql engine will be interface
> org.apache.ignite.internal.index.Index and derived
> org.apache.ignite.internal.index.SortedIndex. A few changes is required to
> those interfaces though: the {{scan}} methods should be reworked in the
> following way:
> {code:java}
> // for Index.java scan should look like this one
> Publisher<BinaryTuple> scan(int partId, InternalTransaction tx, BinaryTuple
> key, BitSet columnsToInclude)
> // for SortedIndex.java range scan should look like this
> Publisher<BinaryTuple> scan(int partId, InternalTransaction tx, @Nullable
> BinaryTuple leftBound, @Nullable BinaryTuple rightBound, int flags, BitSet
> columnsToInclude)
> {code}
> Besides, we need to reconsider the way we work with an index conditions.
> Currently we stick with Ignite-2 way, where search row is represented by a
> tuple of the same size as table row, but only indexed columns is set to a
> particular values while others are set to null. For example for table (id,
> project_id, command_id, name) and index (command_id, project_id) a search
> tuple looks like (null, <project_id_condition>, <command_id_condition>,
> null). We need to rework this in a way to make a search tuple match the
> actual order of indexed columns. With that said, the search tuple for the
> example above should look like (<command_id_condition>,
> <project_id_condition>).
> Finally, since both table and index scan have the very similar API, it seems
> reasonable to rework
> {{org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode}} in a way to
> cover both cases (table scan and index scan).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
