Expand description
Intra-query parallelism under one process-wide thread budget.
A long read (an aggregate over a million records, an exact vector scan)
can split its key range into parts and run them on scoped threads. Every
query draws helper threads from one shared budget, sized to the server’s
worker threads (RUSHDB_THREADS), so concurrent queries never run more
threads than the host was given: a query that finds the budget spent runs
its parts on its own thread. Parts are numbered and their results are
returned in part order, so a caller that merges them in order gets the
same answer as a sequential run whatever the timing.
Functions§
- budget
- The helper-thread budget
set_threadsconfigured. - parts_
for - How many parts a job of
unitsshould split into: one per helper the budget has plus the caller, and none smaller thanmin_units. - run_
parts - Run
part(0..parts)and return the results in part order. Parts run on the calling thread plus as many helper threads as the shared budget lends right now (at mostparts - 1); with none free, they run one after another here. The first error (by part order) is returned. - set_
threads - Set the helper-thread budget: the host’s worker threads less the one
each query already runs on. Called once at startup;
0= run every part on the calling thread. - split
- Split
0..leninto at mostpartscontiguous ranges of near-equal size, in order (no empty ranges).