Open msirek opened 1 year ago
There are some ideas in The Tail at Scale that could help with this. For example, the "Tied requests" idea where we wait for the 95th percentile local region response time before starting the remote scan.
Thinking more about this, maybe we would want there to be two (or more) implementations of UNION ALL that the optimizer could pick between, analogous to different join algorithms. Then the plan would show which behavior was being used.
Please correct me if I am wrong, previously the major reason for disabling the parallel execution for UNION ALL statement was due to its unbounded parallelism that can potential bog down the entire DB instance. Why not just introduce a hard limit in settings such that the maximum concurrency can never be X, and allow users to tweak the value if necessary.
We're considering this for 24.1, but with no commitment.
Is your feature request related to a problem? Please describe. Locality-optimized scan internally creates a UNION ALL expression to handle reading from local and remote regions in separate scans. Currently the UNION ALL branches are executed serially (one after the other), incurring a latency penalty. We wait until a response to the local scan is received before initiating the remote scan.
Describe the solution you'd like Initiate execution of the branches of UNION ALL expressions in parallel.
Describe alternatives you've considered None
Jira issue: CRDB-19356