ThreadPool: high priority queue mode in PS 5.5
High priority scheduling introduced in
https:/
controls whether statements executed by already started transactions go
into the high priority queue.
In some cases it is required to prioritize all statements for a specific
connection regardless of whether they are executed as a part of a
multi-statement transaction or in the autocommit mode. Or vice versa,
some connections may require using the low priority queue for all
statements unconditionally.
The goal of this blueprint is to implement a new system variable,
thread_
high priority scheduling either globally or per connection.
Blueprint information
- Status:
- Complete
- Approver:
- Alexey Kopytov
- Priority:
- High
- Drafter:
- Alexey Kopytov
- Direction:
- Approved
- Assignee:
- Alexey Kopytov
- Definition:
- Approved
- Series goal:
- Accepted for 5.5
- Implementation:
-
Implemented
- Milestone target:
-
5.5.35-33.0
- Started by
- Alexey Kopytov
- Completed by
- Alexey Kopytov
Whiteboard
thread_
- “transactions” (the default). In this mode only statements from already
started transactions may go into the high priority queue depending on
the number of high priority tickets currently available in a
connection (see thread_
- “statements”. In this mode all individual statements go into the high
priority queue, regardless of connection’s transactional state and the
number of available high priority tickets. This value can be used to
prioritize AUTOCOMMIT transactions or other kinds of statements such as
administrative ones for specific connections. Note that setting this
value globally essentially disables high priority scheduling, since in
this case all statements from all connections will use a single queue
(the high priority one);
- “none”. This mode disables high priority queue for a connection. Some
connections (e.g. monitoring) may be insensitive to execution latency
and/or never allocate any server resources that would otherwise impact
performance in other connections and thus, do not really require high
priority scheduling. Note that setting thread_
“none” globally has essentially the same effect as setting it to
“statements” globally: all connections will always use a single queue
(the low priority one in this case).
