20.1.?ux_stat_statements视图

由该模块收集的统计信息可以通过一个名为ux_stat_statements的视图使用。这个视图为每一个可区分的数据库ID、用户ID和查询ID(最多到该模块可以追踪的可区分语句的数量)的组合都包含一行。

表?20.1.?ux_stat_statements列

类型引用描述
useridoidux_authid.oid执行该语句的用户的OID。
dbidoidux_database.oid在其中执行该语句的数据库的OID。
queryidbigint?内部哈希码,从语句的解析树计算得来。
querytext?语句的文本形式。
callsbigint?被执行的次数。
total_timedouble precision?在该语句中花费的总时间,以毫秒计。
min_timedouble precision?在该语句中花费的最小时间,以毫秒计。
max_timedouble precision?在该语句中花费的最大时间,以毫秒计。
mean_timedouble precision?在该语句中花费的平均时间,以毫秒计。
stddev_timedouble precision?在该语句中花费时间的总体标准偏差,以毫秒计。
rowsbigint?该语句检索或影响的行总数。
shared_blks_hitbigint?该语句造成的共享块缓冲命中总数。
shared_blks_readbigint?该语句读取的共享块的总数。
shared_blks_dirtiedbigint?该语句造成的脏共享块的总数。
shared_blks_writtenbigint?该语句写入的共享块的总数。
local_blks_hitbigint?该语句造成的本地块缓冲命中总数。
local_blks_readbigint?该语句读取的本地块的总数。
local_blks_dirtiedbigint?该语句造成的脏本地块的总数。
local_blks_writtenbigint?该语句写入的本地块的总数。
temp_blks_readbigint?该语句读取的临时块的总数。
temp_blks_writtenbigint?该语句写入的临时块的总数。
blk_read_timedouble precision?该语句花在读取块上的总时间,以毫秒计(如果track_io_timing被启用,否则为零)。
blk_write_timedouble precision?该语句花在写入块上的总时间,以毫秒计(如果track_io_timing被启用,否则为零)。

由于安全性原因,只有超级用户和ux_read_all_stats角色的成员被允许看到其他用户执行的查询的SQL文本或者queryid。不过,如果该视图被安装在其他用户的数据库中,那么他们就能够看见统计信息。

只要可规划的查询(即SELECT、INSERT、UPDATE以及DELETE)根据一种内部哈希计算具有相同的查询结构,它们就会被组合到一个单一的ux_stat_statements项。通常,如果两个查询除了查询中的文本常量值之外在语义上等效,它们将会被认为是相同的。不过,功能性命令(即所有其他命令)会严格地以它们的文本查询字符串为基础进行比较。

当为了把一个查询与其他查询匹配,常数值会被忽略,在ux_stat_statements显示中它会被一个参数符号,比如$1所替换。查询文本的剩余部分就是具有与该ux_stat_statements项相关的特定queryid哈希值的第一个查询的文本。

在某些情况中,具有明显不同文本的查询可能会被融合到一个单一的ux_stat_statements项。通常这只会发生在语义等价的查询身上,但是也有很小的机会因为哈希碰撞的原因导致无关的查询被融合到一个项中(不过,对于属于不同用户或数据库的查询来说不会发生这种情况)。

由于queryid哈希值是根据查询被解析和分析后的表达计算的,对立的情况也可能存在:如果具有相同文本的查询由于参数(如不同的search_path设置)的原因而具有不同的含义,它们就可能作为不同的项存在。

ux_stat_statements的使用者可能希望使用queryid(也许会与dbid和userid组合)作为比查询文本更稳定和可靠的每个条目的标识符。但是,有一点很重要的是,对于queryid哈希值稳定性只有有限的保障。因为该标识符是从post-parse-analysis tree得来的,它的值是以这种形式出现的内部对象标识符的函数。这有一些违背直觉的含义,例如:如果有两个查询引用了同一个表,但是该表在两次查询之间被删除并且重建,显然这两个查询是完全一致的,但是ux_stat_statements将把它们认为是不同的。哈希处理也对机器架构以及平台的其他方面的差别很敏感。更进一步,假定queryid在UXDB的主要版本中都是稳定的是不安全的。

根据经验,只有在底层服务器版本以及目录元数据细节保持完全相同时,queryid值才能被假定为稳定并且可比。两台参与到基于物理WAL重放的复制中的服务器会对相同的查询给出一样的queryid值。但是,逻辑复制模式并不保证在所有相关细节上都保持完全一样的复制,因此在逻辑复制机之间计算代价时,queryid并非是一个有用的标识符。

代表性查询文本中用于替换常量的参数符号从原始查询文本中最高的$n参数之后的下一个数字开始,如果没有则为$1。值得注意的是,在某些情况下,可能存在影响编号的隐藏参数符号。例如,PL/uxSQL使用隐藏参数符号将函数局部变量的值插入到查询中,以便像SELECT i + 1 INTO j的PL/uxSQL语句将具有像SELECT i + $2这样的代表性文本。

有代表性的查询文本被保存在一个外部磁盘文件中,并且不会消耗共享内存。因此,即便是很长的查询文本也能被成功存储。不过,如果累积了很多长查询文本,该外部文件也会增长到很大。作为一种恢复方法,如果这样的情况发生,ux_stat_statements可能会选择丢弃这些查询文本,于是ux_stat_statements视图中的所有现有项将会显示空的query域,不过与每个queryid相关联的统计信息会被保留下来。如果发生这种情况,可以考虑减小ux_stat_statements.max来防止复发。

XML 地图 | Sitemap 地图