[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17748:
-------------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
> Labels: ignite-3
>
> 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)
