Skip to content

kv: only scan separated intents span for QueryResolvedTimestamp requests #69717

@nvb

Description

@nvb

Related to #67562 and #67554.
This optimization was originally outlined in the bounded staleness RFC.

Today, a QueryResolvedTimestamp request performs a scan over the MVCC keyspace to retrieve the intents in its target key span.

// computeMinIntentTimestamp scans the specified key span and determines the
// minimum timestamp of any intent. While doing so, it also collects and returns
// up to maxEncounteredIntents intents that are older than intentCleanupThresh.
func computeMinIntentTimestamp(
reader storage.Reader,
span roachpb.Span,
maxEncounteredIntents int64,
maxEncounteredIntentKeyBytes int64,
intentCleanupThresh hlc.Timestamp,
) (hlc.Timestamp, []roachpb.Intent, error) {
iter := reader.NewMVCCIterator(storage.MVCCKeyAndIntentsIterKind, storage.IterOptions{
LowerBound: span.Key,
UpperBound: span.EndKey,
})

With intents now separated out into a separate keyspace, we should be able to perform a more efficient scan over the lock table keyspace to retrieve the active intents on the QueryResolvedTimestamp's target key span. This avoids the need to merge the lock table iterator with an MVCC iterator. As a result, we turn an O(num_keys_in_span) operation into an O(num_locks_in_span) operation.

This is a reasonably hard blocker for stage 2 of bounded staleness reads.

Metadata

Metadata

Assignees

Labels

A-kv-transactionsRelating to MVCC and the transactional model.C-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)C-performancePerf of queries or internals. Solution not expected to change functional behavior.T-kvKV Team

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions