-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Query Execution
-
Fully Compatible
-
QE 2023-05-15, QE 2023-05-29, QE 2023-06-12, QE 2023-06-26, QE 2023-07-10, QE 2023-07-24, QE 2023-08-07, QE 2023-08-21, QE 2023-09-04, QE 2023-09-18, QE 2023-10-02, QE 2023-10-16, QE 2023-10-30, QE 2023-11-13, QE 2023-11-27, QE 2023-12-11, QE 2023-12-25, QE 2024-01-08, QE 2024-01-22, QE 2024-02-05, QE 2024-02-19, QE 2024-03-04, QE 2024-03-18, QE 2024-04-01
-
144
Not all SBE stages that introduce unbounded iteration check for interrupts.
Ideally, we would like to guarantee that during query execution that the interval between checkForInterrupt calls is bounded.
Proposed set of rules to achieve that:
1) Stages that are source of iterations (scan, coscan, unwind, sort, group, spool) should perform checkForInterrupt at least once per unit of work / getNext.
2) Prolonged blocking computation (like sorting) should also periodically perform checkForInterrupt.
3) Stages that are not source of iteration (project, nlj, filter, limit, union, merge) don't need to perform checkForInterrupt, as long as they call a subtree methods that do.
The "source of iteration" refers to stage ability to iterate over more than 1 row for each input row (if exists). Note: filter, nlj stages does introduce a loop, but it are not a source of iteration, as each input row maps to 0-1 output rows, rather than 0-N output rows like unwind.
- depends on
-
-
- Closed
-
- is related to
-
SERVER-86504 Better observability for operations which exceed yielding and interrupt deadlines
-
- In Progress
-
-
SERVER-86164 Create a test that catches operations that aren't interruptible for significant periods of time
-
- Backlog
-