Postgresql中的explain (4)

另一种额外信息是过滤条件过滤掉的记录数：

EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE ten < 7; QUERY PLAN --------------------------------------------------------------------------------------------------------- Seq Scan on tenk1 (cost=0.00..483.00 rows=7000 width=244) (actual time=0.016..5.107 rows=7000 loops=1) Filter: (ten < 7) Rows Removed by Filter: 3000 Total runtime: 5.905 ms

这个值在join节点上尤其有价值。"Rows Removed"只有在过滤条件过滤掉数据时才显示。

类似条件过滤的情况也会在"lossy"索引扫描时发生，比如这样一个查询，一个多边形含有的特定的点：

EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)'; QUERY PLAN ------------------------------------------------------------------------------------------------------ Seq Scan on polygon_tbl (cost=0.00..1.05 rows=1 width=32) (actual time=0.044..0.044 rows=0 loops=1) Filter: (f1 @> '((0.5,2))'::polygon) Rows Removed by Filter: 4 Total runtime: 0.083 ms

规划器认为（正确的）这样的表太小以至于不需要索引扫描，所以采用顺序扫描所有行经行条件检查。

但是，如果我们强制使用索引扫描，将会看到：

SET enable_seqscan TO off; EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------- Index Scan using gpolygonind on polygon_tbl (cost=0.13..8.15 rows=1 width=32) (actual time=0.062..0.062 rows=0 loops=1) Index Cond: (f1 @> '((0.5,2))'::polygon) Rows Removed by Index Recheck: 1 Total runtime: 0.144 ms

这里我们可以看到索引返回一条候选数据，但被过滤条件拒绝。这是因为GiST索引在多边形包含检测上是松散的"lossy"：它实际返回哪些和多边形交叠的数据，然后我们还需要针对这些数据做包含检测。

EXPLAIN还有BUFFERS选项可以和ANALYZE一起使用，来得到更多的运行时间分析：

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on tenk1 (cost=25.08..60.21 rows=10 width=244) (actual time=0.323..0.342 rows=10 loops=1) Recheck Cond: ((unique1 < 100) AND (unique2 > 9000)) Buffers: shared hit=15 -> BitmapAnd (cost=25.08..25.08 rows=10 width=0) (actual time=0.309..0.309 rows=0 loops=1) Buffers: shared hit=7 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1) Index Cond: (unique1 < 100) Buffers: shared hit=2 -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0) (actual time=0.227..0.227 rows=999 loops=1) Index Cond: (unique2 > 9000) Buffers: shared hit=5 Total runtime: 0.423 ms

Buffers提供的数据可以帮助确定哪些查询是I/O密集型的。

请注意EXPLAIN ANALYZE实际运行查询，任何实际影响都会发生。如果要分析一个修改数据的查询又不想改变你的表，你可以使用roll back命令进行回滚，比如：

BEGIN; EXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 < 100; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Update on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=14.628..14.628 rows=0 loops=1) -> Bitmap Heap Scan on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=0.101..0.439 rows=100 loops=1) Recheck Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1) Index Cond: (unique1 < 100) Total runtime: 14.727 ms ROLLBACK;

当查询是INSERT,UPDATE或DELETE命令时，在顶级节点是实施对表的变更。在这下面的节点实行定位旧数据计算新数据的工作。所以我们看到一样的bitmap索引扫描，并返回给Update节点。值得注意的是虽然修改数据的节点可能需要相当长的运行时间（在这里它消耗了大部分的时间），规划器却没有再评估时间中添加任何消耗，这是因为更新工作对于任何查询规划都是一样的，所以并不影响规划器的决策。

EXPLAIN ANALYZE的"Total runtime"包括执行启动和关闭时间，以及运行被激发的任何处触发器的时间，但不包括分析、重写或规划时间。执行时间包括BEFORE触发器，但不包括AFTER触发器，因为AFTER是在查询运行结束之后才触发的。每个触发器（无论BEFORE还是AFTER）的时间也会单独显示出来。注意，延迟的触发器在事务结束前都不会被执行，所以EXPLAIN ANALYZE不会显示。