Details
-
New Feature
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Do
-
None
-
None
Description
In primproc, right now if a short-running query comes in while a long-running one is running, its jobs must wait for all of the large query's jobs to complete before it can run. This impacts everyone using CS for real-time queries and anything else from the same cluster. Prioritizing new queries and small queries over old ones would fix this.
Modifications include:
- Modifying PriorityThreadPool to track the total 'scheduled time' of each query (session id at that level iirc) from create to destroy.
- ... as a query accumulates more 'scheduled time', PTP demotes it to lower priority queues.
- Modifying the jobsteps dictionary-scan and tuplebps to estimate the weight of their work (a simple metric will likely be good enough, ie, the # of blocks to be touched), and propagate this info to primproc so it can insert a query's jobs into the appropriate queue
- Modifying JobList to sum the estimates from each jobstep and make the # available to jobsteps.