Groups have two properties; the set of users who are members, and the set of privileges granted to the group.
Groups can never be the owner of an object, or issue queries, or anything like that; all there is, is which users are in the group, and which privileges are granted to the group.
However, if we take the set of users in a group and aggregate information about those users, we can quite reasonably say this is information about that group, and this is the approach I’ve taken.
There is a page for groups at the cluster level, but where at the cluster level it is not possible to know which objects belong to which user, the information there is incomplete.
This page is for groups, but it uses the system tables in the current database, and so know is able to know which objects (in this database) belong to which user (and so to which groups), and so is able to provide the normal, current complete set of information.
| Name | Type |
|---|---|
| group_id | int4 |
| group | varchar |
| idle | interval |
| objects::schemas | int8 |
| objects::tables | int8 |
| objects:views:normal | int8 |
| objects:views:late-binding | int8 |
| objects:views:materialized | int8 |
| objects::procedures | int8 |
| objects::functions | int8 |
| queries:worker:main | int8 |
| queries:worker:csc | int8 |
| store:blocks:sorted | int8 |
| store:blocks:unsorted | int8 |
| store:blocks:total | int8 |
| store:rows:sorted | int8 |
| store:rows:unsorted | int8 |
| store:rows:total | 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 group ID. This column is emitted in CSV exports only.
Group IDs are unique across all databases.
The group name.
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 number of procedures owned by users in the group, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of tables owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of normal views owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of late-binding views owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of materialized views owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of procedures owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The number of functions owned by users in the group, present in the schema, or owned by the user (depending on which page you’re on, to be viewing this column).
The count of worker node queries completed on the cluster.
The count of worker node queries completed by a CSC cluster.
The number of sorted blocks.
The number of unsorted blocks.
The total number of blocks.
The number of sorted rows.
The number of unsorted rows.
The total number of rows.
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.