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:port | calls | total_time / calls | total_time | unit total_time | rows / calls | total rows | query |
---|---|---|---|---|---|---|---|
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 |
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.