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

["Yury Gerzhedovich (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17628819#comment-17628819 ] 

Yury Gerzhedovich commented on IGNITE-17748:
--------------------------------------------

[~amashenkov] , LGTM

> 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
>            Assignee: Andrey Mashenkov
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta1
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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
> {code:java}
> Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx, @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code}
> and following method for sorted index scanning
> {code:java}
> Publisher<BinaryTuple> scan(int partId, @Nullable InternalTransaction tx, @NotNull 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.
> h3. UPD:
> As was discussed, indexId will be always specified so that tables internals will never select PK-index or any other by themselves, so that @Nullable UUID indexId is now @NotNull UUID indexId.
>  
> Besides API extension itself, it's required to build a bridge between https://issues.apache.org/jira/browse/IGNITE-17655 and internalTable.scan API, meaaning that it's required to create implementations for sql index interfaces introduced in 17655 that will propagate index scans to corresponding internalTable.scan API.



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