PostgresSQL-规划器使用的统计信息
2015-01-30 00:00
155 查看
13.2. 规划器使用的统计信息
就象我们在上一节里展示的那样,查询规划器需要估计一个查询检索的行的数目,这样才能选择正确的查询规划。 本节就系统用于这些估计的统计进行一些描述。统计的一个部分就是每个表和索引中的记录总数,以及每个表和索引占据的磁盘块数。 这个信息保存在 pg_class 的 reltuples 和 relpages 字段中。我们可以用类似下面的查询检索这些信息:
relname LIKE 'tenk1%'; relname | relkind | reltuples | relpages ----------------------+---------+-----------+---------- tenk1 | r | 10000 | 358 tenk1_hundred | i | 10000 | 30 tenk1_thous_tenthous | i | 10000 | 30 tenk1_unique1 | i | 10000 | 30 tenk1_unique2 | i | 10000 | 30 (5 rows)
我们在这里可以看到 tenk1 有 10000 行, 它的索引也有这么多行,但是索引远比表小得多(很正常)。
出于效率考虑,reltuples 和 relpages 不是实时更新的, 因此它们通常包含可能有些过时的数值。 它们被 VACUUM,ANALYZE,和几个 DDL 命令,比如 CREATE INDEX 更新。一个独立的&nb
7fe0
sp;ANALYZE, 也就是没有和 VACUUM 在一起的, 生成一个reltuples 的近似数值, 因为它并没有读取表里的每一行。规划器将把 pg_class 表里面的数值调整为和当前的物理表尺寸匹配,以此获取一个更接近的近似值。
大多数查询只是检索表中行的一部分,因为它们有限制待查行的 WHERE 子句。 因此规划器需要对WHERE子句的选择性(selectivity)进行评估, 选择性也就是符合WHERE子句中每个条件的部分。 用于这个目的的信息存储在 pg_statistic 系统表中。 在 pg_statistic 中的记录是由 ANALYZE 和 VACUUM ANALYZE 命令更新的, 并且总是近似值,即使刚刚更新完也不例外。
除了直接查看 pg_statistic 之外, 我们手工检查统计的时候最好查看它的视图 pg_stats。 pg_stats 设计成更具可读性。 而且,pg_stats 是所有人都可以读取的, 而 pg_statistic只能由超级用户读取。 (这样就可以避免非特权用户从统计信息中获取一些和其他人的表内容相关的信息。 pg_stats 视图是受约束的,只显示当前用户可读的表。) 比如,我们可以∶
SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'road'; attname | n_distinct | most_common_vals ---------+------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- name | -0.467008 | {"I- 580 Ramp","I- 880 Ramp","Sp Railroad ","I- 580 ","I- 680 Ramp","I- 80 Ramp","14th St ","5th St ","Mission Blvd","I- 880 "} thepath | 20 | {"[(-122.089,37.71),(-122.0886,37.711)]"} (2 rows)
pg_stats 在 Section 42.43 里详细描述。
在 pg_statistic 李存储的信息的数量,特别是 给每个字段用的 most_common_vals 和 histogram_bounds 数组上的最大记录数目可以用 ALTER TABLE SET STATISTICS 命令设置, 或者是用运行时参数 default_statistics_target 进行全局设置。 目前缺省的限制是 10 个记录。 提升该限制应该可以做出更准确的规划器估计,特别是对那些有不规则数据分布的字段而言, 付出的代价是在 pg_statistic 里使用了更多空间,并且需要略微多一些的时间计算估计数值。 相比之下,比较低的限制可能更适合那些数据分布比较简单的字段
相关文章推荐
- SQL优化----如何使用工具快速诊断出统计信息有问题?
- 使用v$sql_monitor视图查看当前正在运行的SQL语句的统计信息
- 从一个SQL使用了不理想的执行计划说开,浅谈执行计划如何估算cache信息的影响及系统统计信息的收集等(2010-10-15)
- DBCC大全集之(适用版本MS SQLServer 2008 R2)----DBCC SQLPERF提供所有数据库的事务日志空间使用情况统计信息
- Microsoft SQL Server 2005中查询优化器使用的统计信息
- Postgres8.3.3增强版(添加SQL执行信息统计功能)
- 查询优化器如何使用(索引)统计信息 (How the Query Optimizer Uses Statistics)
- 关于统计的一个sql问题,使用动态sql语句实现。
- sql,scope_identity,procedure,tran,substring,cast,convert,charindex,插入角色的同时插入角色拥有的权限,权限使用权限列表表示,列表用逗号分隔权限的id,更新角色信息,同时更新权限信息
- 使用 atmadm 来显示 ATM 适配器上传入和传出呼叫的统计信息
- 如何修改栈结构统计每个DLL的函数使用信息
- PostgreSQL SQL的性能调试方法1--借助统计信息
- 使用SQL语句为表的字段添加描述信息
- SQL统计哪些表使用分区表
- 一次使用SQL对考试结果进行统计的小经验
- SQL统计大全收藏版-个人使用
- SQL 2005 如何统计sql执行信息
- SQL语句笔记,增加一个字段,统计该表内的数据信息
- SQL2000系统表、存储过程、函数的功能介绍及应用2009年01月21日 星期三 11:38虽然使用系统存储过程、系统函数与信息架构视图已经可以为我们提供了相当丰富的元数据信息,但是对于某些特殊的元数据信息,我们仍然需要直接对系统表进行查询。因为SQL
- Solaris 内核统计信息 - 使用C访问libkstat