Skip to content

Conversation

mronstro
Copy link
Collaborator

No description provided.

Supporting higher parallelism in scans

A configuration variable that can disable or enable this feature.
…us scan

Supporting higher parallelism in scans

The feature is only supported for ReadCommitted and when the configuration
supports it. This means that a flag is needed in both SCAN_FRAGREQ and
SCAN_TABREQ that specifies whether it is used or not. Adapted also
signal printers.
Supporting higher parallelism in scans

DBTC needs to maintain four times as many receiver id's as the parallelism.
Thus the parallelism is a fourth of the number of receiver objects.
We have to track which receiver object to use for the moment and store
the receiver objects used by the various fragment scans.
Supporting higher parallelism in scans

We support being one scan ahead for continous scans.
This means that the NDB API can receive the first batch,
the second batch and even a third batch and still immediately
respond to DBTC for continued scans. But if three batches
have been requested we have to wait until DBLQH signals the
first batch (through DBTC) completed until we send the fourth
batch. The reason is that DBLQH can work on the fourth batch
if three batches have been requested.

To support this DBLQH needs access to all four receiver objects,
it also need a new state tracking where in the continous scan
process it is. DBLQH keeps track of which receiver object to use
it, thus synchronisation between NDB API and DBLQH is algorithmic
and not using any special communication.

The main benefit for DBLQH scans is that when it returns SCAN_FRAGCONF
it previously had to wait for SCAN_NEXTREQ until it could continue
scanning. Now it can continue scanning the next batch immediately.
Thus we only need to stop scanning in DBLQH if the return of
SCAN_NEXTREQ happens after completed the next batch. Thus normally
we would get continous scanning in DBLQH, thus the name continous
scanning.
Supporting higher parallelism in scans

The most complex part of supporting continous scans is for sorted
scans on ordered indexes. This requires a fairly complex state
machine tracking the state of all concurrent fragment scans
and ensuring that we enter wait states when appropriate.

It is important to get this part right since much of the
performance improvements comes from avoiding too many wait states
and do as much batching as possible without overusing memory.

A lot of new debugging is added to support this.

The NdbReceiver added a new variable with its index in the array
of NdbReceiver to make it easy to correlate to its state. A new
state for NdbReceiver objects was introduced with 7 different
states.

Some minor changes to handling SCAN_TABCONF was required.

The handling of nextResult for continous scans with sorting is a
completely new method to avoid complicating the existing code.
@mronstro mronstro changed the base branch from 24.10-main to 25.10-main October 16, 2025 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants