You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Konstantin Orlov (Jira)" <ji...@apache.org> on 2022/09/08 11:49:00 UTC

[jira] [Updated] (IGNITE-17655) Sql. Provide integration for index scan

     [ https://issues.apache.org/jira/browse/IGNITE-17655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konstantin Orlov updated IGNITE-17655:
--------------------------------------
    Ignite Flags:   (was: Docs Required,Release Notes Required)

> 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, @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).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)