This page provides information about the slices in the cluster.
Name | Type |
---|---|
node | int2 |
slice | int2 |
slice:type | varchar |
idle | interval |
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 |
The node ID. Nodes count from 0 and are contiguous.
The slice ID. Slices count from 0 and are contiguous and unique across all nodes.
There is a single special case “slice”, which used to be number 6411 but now seems to be a value which varies by query and which is slightly above 12800, and this is in fact the leader node.
This column indicates the slice types.
For ra3
type nodes, there are two slice types,
full
and partial
.
For the other node types, there is only the one slice type,
full
.
In AWS parlance, a full
slice is a data
slice, and partial
slice is a compute
slice.
A full
slice is the normal, usual,
it’s-always-been-like-this slice, which is fully-featured, participates
in all step types, owns part of each table, can access disk, S3, RMS,
etc.
A partial
slice is a recent addition and is used to help
ameliorate a drawback of elastic resize.
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 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.
It is the leader node returns rows to the SQL client, so for this page, this column is the number of rows returned to the leader node.
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.