Users in and of themselves have only a couple of properties of note; their name, their type (e.g. admin or normal), and whether or not they have restricted or unrestricted access to the system tables.
In Redshift, there is the cluster, and there are the databases, and some information is about the cluster, such as nodes or queries, and some information is per database, such as tables or functions.
This page shows cluster information only. (See database_users_v1 for the per-database information.)
Currently, this page shows information about number of queries issued per user, and disk I/O per user.
Name | Type |
---|---|
user_id | int4 |
user | varchar |
type | varchar |
syslog | varchar |
idle | interval |
queries:leader:main | int8 |
queries:worker:main | int8 |
queries:worker:csc | int8 |
i/o:bytes read:disk | int8 |
i/o:bytes read:network | int8 |
i/o:rows:inserted | int8 |
i/o:rows:deleted | int8 |
i/o:rows:returned | int8 |
i/o:bytes processed:in memory | int8 |
i/o:bytes processed:on disk | int8 |
related pages | varchar |
The user ID. This column is emitted in CSV exports only.
The user name.
type | meaning |
---|---|
root | the AWS root user |
super | a normal superuser |
(empty) | a normal user |
Set to ‘restricted’ if syslog access is set to restricted, ‘unrestricted’ if unrestricted.
Duration since the start of most recent table access in
stl_delete
, stl_insert
and
stl_scan
, which is to say, the time since the table last
had rows deleted, inserted, or was scanned. If empty, there are no
records in any of these system tables within the time period being
examined by the page.
The most accurate obtainable count of leader node queries, both running and completed, issued by the users in this group.
Currently (2022-12-25) there appears to be a regression in
stv_recents
, which is the only system table holding
information about running leader node queries, such that running leader
node queries are not shown; only completed queries.
Additionally, certain types of query (such as select
)
have, as far as I know, no record in the system tables other than in
stv_recents
, which holds only the most recent 100
queries.
As such the information about completed leader node queries, although fairly complete, is not fully complete.
The count of worker node queries completed on the cluster.
The count of worker node queries completed by a CSC cluster.
This column then shows the total number of bytes read from disk, as
best I can judge the types indicated in stl_scan
.
This column then shows the total number of bytes read from network,
as best I can judge the types indicated in stl_scan
.
Importantly, it only counts the receive side of network
activity - the step is scan
, after all, not
broadcast
, so we’re not counting bytes twice.
The number of rows inserted into the table.
For tables with all
distribution, this is the physical
number of rows (i.e. one per node), not the logical number of rows.
The number of rows deleted from the table.
For tables with all
distribution, this is the physical
number of rows (i.e. one per node), not the logical number of rows.
The number of rows returned from the leader node to the SQL client.
This column then shows the total number of bytes processed by the
stl_aggr
, stl_hash
, stl_save
,
stl_sort
and stl_unique
steps, when running in
memory rather than on disk.
This column then shows the total number of bytes processed by the
stl_aggr
, stl_hash
, stl_save
,
stl_sort
and stl_unique
steps, when running on
disk rather than in memory.