[jira] [Commented] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans
[ https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 scan(int partId, @Nullable InternalTransaction tx, > @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code} > and following method for sorted index scanning > {code:java} > Publisher 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)
[jira] [Commented] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans
[ https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622638#comment-17622638 ] Stanislav Lukyanov commented on IGNITE-17748: - [~amashenkov] do you have an ETA for this? > 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 > > > 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 scan(int partId, @Nullable InternalTransaction tx, > @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code} > and following method for sorted index scanning > {code:java} > Publisher 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)