Statement statistics

In the output generated by ad-hoc or snapshot-diff mode, a fourth group that optionally can be shown are statement statistics. These statistics are taken from the YSQL (normally port 13000) http endpoint. If no SQL interaction did happen between YSQL/postgres and DocDB, then there will be no statements shown.

This is how the statement output looks like:

192.168.66.80:13000          98 avg:           0.002 tot:           0.156 ms avg:          0 tot:          0 rows: begin
192.168.66.80:13000          98 avg:           0.003 tot:           0.305 ms avg:          0 tot:          0 rows: commit
192.168.66.80:13000          98 avg:          78.722 tot:        7714.786 ms avg:       1020 tot:     100000 rows: copy ysql_bench_accounts from stdin
192.168.66.80:13000           1 avg:         456.096 tot:         456.096 ms avg:          0 tot:          0 rows: create table ysql_bench_accounts(aid    int not null,bid int,abalance int,filler
192.168.66.80:13000           1 avg:         451.798 tot:         451.798 ms avg:          0 tot:          0 rows: create table ysql_bench_branches(bid int not null,bbalance int,filler char(88),P
192.168.66.80:13000           1 avg:         483.839 tot:         483.839 ms avg:          0 tot:          0 rows: create table ysql_bench_history(tid int,bid int,aid    int,delta int,mtime times
192.168.66.80:13000           1 avg:         394.892 tot:         394.892 ms avg:          0 tot:          0 rows: create table ysql_bench_tellers(tid int not null,bid int,tbalance int,filler cha
192.168.66.80:13000           1 avg:         569.624 tot:         569.624 ms avg:          0 tot:          0 rows: drop table if exists ysql_bench_accounts, ysql_bench_branches, ysql_bench_histor
192.168.66.80:13000           1 avg:          11.560 tot:          11.560 ms avg:          1 tot:          1 rows: insert into ysql_bench_branches(bid,bbalance) values($1,$2)
192.168.66.80:13000          10 avg:           8.218 tot:          82.179 ms avg:          1 tot:         10 rows: insert into ysql_bench_tellers(tid,bid,tbalance) values ($1,$2,$3)
192.168.66.80:13000           1 avg:        6641.962 tot:        6641.962 ms avg:          0 tot:          0 rows: truncate table ysql_bench_accounts, ysql_bench_branches, ysql_bench_history, ysq

Explanation:

hostname:portcallstotal_time / callstotal_timeunit total_timerows / callstotal rowsquery
192.168.66.80:1300098avg: 0.002tot: 0.156msavg: 0tot: 0 rowsbegin
192.168.66.80:1300098avg: 0.003tot: 0.305msavg: 0tot: 0 rowscommit
192.168.66.80:1300098avg: 78.722tot: 7714.786msavg: 1020tot: 100000 rowscopy ysql_bench_accounts from stdin
192.168.66.80:130001avg: 456.096tot: 456.096msavg: 0tot: 0 rowscreate table ysql_bench_accounts(aid int not null,bid int,abalance int,filler
192.168.66.80:130001avg: 451.798tot: 451.798msavg: 0tot: 0 rowscreate table ysql_bench_branches(bid int not null,bbalance int,filler char(88),P
192.168.66.80:130001avg: 483.839tot: 483.839msavg: 0tot: 0 rowscreate table ysql_bench_history(tid int,bid int,aid int,delta int,mtime times
192.168.66.80:130001avg: 394.892tot: 394.892msavg: 0tot: 0 rowscreate table ysql_bench_tellers(tid int not null,bid int,tbalance int,filler cha
192.168.66.80:130001avg: 569.624tot: 569.624msavg: 0tot: 0 rowsdrop table if exists ysql_bench_accounts, ysql_bench_branches, ysql_bench_histor
192.168.66.80:130001avg: 11.560tot: 11.560msavg: 1tot: 1 rowsinsert into ysql_bench_branches(bid,bbalance) values($1,$2)
192.168.66.80:1300010avg: 8.218tot: 82.179msavg: 1tot: 10 rowsinsert into ysql_bench_tellers(tid,bid,tbalance) values ($1,$2,$3)
192.168.66.80:130001avg: 6641.962tot: 6641.962msavg: 0tot: 0 rowstruncate table ysql_bench_accounts, ysql_bench_branches, ysql_bench_history, ysq

For the sake of simplicity, any identical SQL (based on the query text) is summed up, and assumed to be the same statement. This is not correct. (at the time of creation, query_id was not exposed, so this was the only solution)

Please mind the source of the SQL statistics is postgres' pg_stat_statements, and holds a few quirks:

  • Any SQL that returns an error is not saved in 'pg_stat_statements'.
  • The 'total_time' is actually the time spent in the execution phase. Especially since YSQL might need to perform RPCs to complete its catalog (in rewrite/semantic parse and plan phases), this can miss some time and therefore show less time than a client sees.
  • A statement's uniqueness in pg_stat_statements is dependent on query_id, dbid and userid. Currently we don't expose all this fields in the http endpoint.