[jira] [Updated] (IGNITE-28315) Improve index row resolution for RO scan

["Konstantin Orlov (Jira)" <ji...@apache.org>]

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

Konstantin Orlov updated IGNITE-28315:
--------------------------------------
    Summary: Improve index row resolution for RO scan  (was: Improve index row resolution )

> Improve index row resolution for RO scan
> ----------------------------------------
>
>                 Key: IGNITE-28315
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28315
>             Project: Ignite
>          Issue Type: Improvement
>          Components: secondary indexes ai3
>            Reporter: Konstantin Orlov
>            Assignee: Konstantin Orlov
>            Priority: Major
>              Labels: ignite-3
>
> Take a look at the method below 
> {code}
>     private CompletableFuture<Void> continueReadOnlyIndexScan(
>             TableSchemaAwareIndexStorage schemaAwareIndexStorage,
>             Cursor<IndexRow> cursor,
>             HybridTimestamp readTimestamp,
>             int batchSize,
>             List<BinaryRow> result,
>             int tableVersion
>     ) {
>         if (result.size() >= batchSize || !cursor.hasNext()) {
>             return nullCompletedFuture();
>         }
>         IndexRow indexRow = cursor.next();
>         RowId rowId = indexRow.rowId();
>         return resolvePlainReadResult(rowId, null, readTimestamp).thenComposeAsync(resolvedReadResult -> {
>             BinaryRow binaryRow = upgrade(binaryRow(resolvedReadResult), tableVersion);
>             if (binaryRow != null && indexRowMatches(indexRow, binaryRow, schemaAwareIndexStorage)) {
>                 result.add(binaryRow);
>             }
>             return continueReadOnlyIndexScan(schemaAwareIndexStorage, cursor, readTimestamp, batchSize, result, tableVersion);
>         }, scanRequestExecutor);
>     }
> {code}
> The issue is that rows are currently processed one at a time. After each row is processed, a new task is scheduled to continue execution. This approach results in a large number of short-lived tasks (one per row, primarily to invoke next on the cursor and perform a single lookup in the B+Tree), which negatively impacts latency.
> Additionally, under high-throughput conditions, task scheduling itself becomes a source of contention on the executor’s queue.



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