explain analyse
SELECT COUNT(*) FROM syo_event WHERE id_group = 'OPPORTUNITY' AND id_type = 'NEW'
我的查询有这个计划:
Aggregate (cost=654.16..654.17 rows=1 width=0) (actual time=3.783..3.783 rows=1 loops=1)
-> Bitmap Heap Scan on syo_event (cost=428.76..654.01 rows=58 width=0) (actual time=2.774..3.686 rows=1703 loops=1)
Recheck Cond: ((id_group = 'OPPORTUNITY'::text) AND (id_type = 'NEW'::text))
-> BitmapAnd (cost=428.76..428.76 rows=58 width=0) (actual time=2.635..2.635 rows=0 loops=1)
-> Bitmap Index Scan on syo_list_group (cost=0.00..35.03 rows=1429 width=0) (actual time=0.261..0.261 rows=2187 loops=1)
Index Cond: (id_group = 'OPPORTUNITY'::text)
-> Bitmap Index Scan on syo_list_type (cost=0.00..393.45 rows=17752 width=0) (actual time=2.177..2.177 rows=17555 loops=1)
Index Cond: (id_type = 'NEW'::text)
Total runtime: 3.827 ms
在第一行:
(actual time=3.783..3.783 rows=1 loops=1
(为什么实际时间与最后一行Total runtime
不匹配?)
在第二行:
cost=428.76..654.01
(以费用428.76开始Bitmap Heap Scan
,以654.01结束)?
rows=58 width=0)
(Wath是rows
和width
,重要的是什么?)
rows=1703
(这是结果)
loops=1)
(用于子查询?)
答案 0 :(得分:2)
来自postgres docs:
请注意,“实际时间”值以实时的毫秒为单位,而成本估算以任意单位表示;所以他们不太可能匹配。通常最重要的事情是估计的行数是否与现实相当接近。
估算的成本计算为(磁盘页读取* seq_page_cost)+(扫描的行数* cpu_tuple_cost)。默认情况下,seq_page_cost为1.0,cpu_tuple_cost为0.01
答案 1 :(得分:1)
对于第一行,var pcontent = ["h", "H", "o", " "],
constpass = (p, ...a) => a.reduce((s,k) => s+=p[k],""),
result = constpass(pcontent, 1, 2, 3, 0, 2, 3, 0, 2);
console.log(result);
执行了查询并花了EXPLAIN
,但向您展示计划的输出需要一些时间,因此总计运行时间增加了所花费的时间。
基本上3.783 ms
会显示普通EXPLAIN ANALYZE
会显示实际运行查询时收集的值的估计值,因此第二行的差异。
行和宽度都很重要。这是行输出估计的行数和以字节为单位的行的平均宽度。如果返回的行数估计较小而您需要考虑到这一点,则估算的总费用会降低。
要了解实际呈现的循环,您需要知道查询计划实际上是计划节点树。有不同类型的节点用于不同的目的 - 例如,扫描节点负责从表中返回原始行。如果您的查询正在对行执行某些操作,则扫描节点上方将有其他节点来处理该操作。
EXPLAIN
输出中的第一行是来自第1级(顶部)节点的摘要,其中包含整个计划的估算成本。
知道, loops 表示特定节点的总执行次数值。这是因为在某些计划中,子计划节点可以执行多次,如果发生这种情况,那么为了使这些数字与其他估计值相当,它会将时间和行值乘以 loops 以获得花费的总时间那个节点。
您可以在documentation。
中更深入地了解该主题