This page lists the WLM routing rules, and also the number of queries routed by each rule.
Redshift does not provide information about which routing rule routed which query; I have to compute it myself.
I take the routing rules, figure out a case statement
which matches how they operate, and then examine all queries which have
been issued (I do not check running queries - it would double the
complexity of the code, for very little gain, as there are at most 50
running queries, but on a busy cluster, 300k completed queries per
day).
Redshift however keeps no history of changes to the WLM routing rules; all you can get is what you have now.
As such, I examine each query with the routing rules as they are now. I can’t know if the routing rules were different at the time the query ran.
Accordingly, if you make changes to the routing rules, you will want to use the “limit” functionality in the page, to restrict the queries processed to within the period covered by the new rules.
Routing rules can be configured to apply to given user groups.
As far as I could tell when making this page (I never use the v2 Redshift console) perform no validation with regard to groups; they can be empty, or even not exist. The rule will still be accepted.
Additionally, wildcards can be specified in group names, and these also may lead to no matches, and this is not checked. (It might be intentional, perhaps the groups will be created, but it might well not be too - at least a warning should be given).
The code I have validates the use of groups, and any problems or
warnings are emitted in the notes column (see the column
description for details).
It used to be there was no way to know from the system tables whether SQA is enabled or disabled - the routing rule for it was always present (and defined with an empty condition!), whether or not SQA was active.
Recently (as of 2023-03-13, when I noticed it), the SQA rule is now absent from the routing table, if SQA is disabled.
In any event, the presence of absence of the SQA routing rule now appears to be how you can tell from the system tables if SQA is active. Note the SQA rule is still defined with an empty condition, which makes it use of that column different to all the other rows.
| Name | Type |
|---|---|
| order | int8 |
| wildcard:query group | bool |
| wildcard:user group | bool |
| condition | varchar |
| queue_id | int2 |
| queue | varchar |
| count | int8 |
| notes | varchar |
Rules are evaluated from the first to the last, and evaluation stops as soon as as rule matches.
This column indicates the order in which rules are processed, the first rule being 1, the last being the highest number.
True if wildcard characters in the query group string are being treated as wildcards, false otherwise (in which case, they are treated as literal characters, not wildcards).
True if wildcard characters in the user group string are being treated as wildcards, false otherwise (in which case, they are treated as literal characters, not wildcards).
The full condition text of the rule.
The queue ID. This column is emitted in CSV exports only.
The queue name.
The default queue is played by Clint Eastwood, for it has no name. I’ve called it “default”.
Number of queries routing by this rule.
When rules are created, no validation is performed. It is then possible to create rules which refer to non-existent user groups, or user groups which are empty. Similarly, wildcard patterns for user groups might match to no groups. This page validates user groups, are produces the following warnings, which are emitted in this column.
When wildcards are disabled, the user group specified in a rule is checked to see it exists, and if it has members. If it does not exist, or is empty, warnings are given
When wildcards are enabled, if the pattern matches no groups at all, a warning is given. Also, if the pattern does match groups, but all matching groups are empty, a warning is given.