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

[jira] [Created] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans

Alexander Lapin created IGNITE-17748:
----------------------------------------

             Summary: Enrich InternalTable.scan API in order to support index scans
                 Key: IGNITE-17748
                 URL: https://issues.apache.org/jira/browse/IGNITE-17748
             Project: Ignite
          Issue Type: Improvement
            Reporter: Alexander Lapin


h3. Motivation

SQL engine might specify index to use for scanning data along with some additional parameters like lower/upper bounds, including/excluding such bounds, columns to include etc. All in all we should enrich InternalTable scan api and provide corresponding data propagation logic. 
h3. Definition of Done

*1.* InternalTable scan API has following method for both hash and sorted indexes scanning
Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx, @Nullable UUID indexId, BinaryTuple key, BitSet columnsToInclude)
and following method for sorted index scanning

 
{code:java}
Publisher<BinaryRow> scan(int partId, @Nullable InternalTransaction tx, @Nullable UUID indexId, @Nullable BinaryTuple leftBound, @Nullable BinaryTuple rightBound, int flags, BitSet columnsToInclude) {code}
Please check org.apache.ignite.internal.storage.index.SortedIndexStorage#scan for flags explanation, briefly

 
{code:java}
flags Control flags. {@link #GREATER} | {@link #LESS} by default. Other available values
* are {@link #GREATER_OR_EQUAL}, {@link #LESS_OR_EQUAL}.{code}
*2.* Besides API itself corresponding scan-meta should be propagated to PartitionReplicaListener, so that some changes are also expected within ScanRetrieveBatchReplicaRequest. Please, pay attention that, that there's, probably, no sense in propagation same scan-meta within every ScanRetrieveBatchReplicaRequest, we might do it only wihtin initial request.

*3.* Proper index is chosen. See optional indexId param and proper method of either IndexStorage or specific SortedIndexStorage is used.
h3. Implementation Notes

Mainly it's all specified in the section above. Seems that there's only one caveat left, however, non trivial one - BinaryRow to Binary tuple convertion, schema involved.



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