Konstantin Orlov created IGNITE-28315:
-----------------------------------------
Summary: Improve index row resolution
Key: IGNITE-28315
URL: https://issues.apache.org/jira/browse/IGNITE-28315
Project: Ignite
Issue Type: Improvement
Components: secondary indexes ai3
Reporter: Konstantin Orlov
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)
