瞭解Postgres的查詢計劃

explain analyse 
SELECT COUNT(*) FROM syo_event WHERE id_group = 'OPPORTUNITY' AND id_type = 'NEW'

我的查詢有這樣的計劃：瞭解Postgres的查詢計劃

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

（啓動Bitmap Heap Scan成本428.76與654.01結束）？

rows=58 width=0)

（Wath是rows和width，什麼重要的事？）

rows=1703

（這是結果）

loops=1)

（子查詢中使用？）

來源

2016-09-15 Tiago Oliveira de Freitas

對於第一線，EXPLAIN執行查詢並花了3.783 ms，但呈現你的計劃的輸出需要一些時間，所以總運行時間會隨着花費的時間而增加。

基本上EXPLAIN ANALYZE顯示估計，一個普通的EXPLAIN會告訴你從實際運行查詢，因此在秒線區別收集值一起。

兩個行和寬度是重要的。這分別是行輸出估計的數量和以字節爲單位的行的平均寬度。如果對返回的行的估計較小，則您的估計總成本將會降低，您需要考慮這一點。

要了解循環究竟呈現你需要知道，查詢計劃實際上是計劃節點樹。有不同類型的節點可用於不同的目的 - 例如掃描節點負責從表中返回原始行。如果您的查詢正在對行進行一些操作，那麼掃描節點上方會有額外的節點來處理這些節點。

從EXPLAIN輸出的第一行是級別1（頂部）節點的摘要，其中包含整個計劃的估計成本。

瞭解到，環表示特定節點的執行總數的值。這是因爲在某些計劃中，可以多次執行一個子計劃節點，如果發生這種情況，可以使數字與其他估計值相比較，它會將時間和行值乘以循環以獲得在該節點中花費的總時間。

您可以在documentation的主題中獲得更多見解。

來源

2016-09-15 17:58:02

從postgres docs：

請注意，「實際時間」值以毫秒爲單位實時顯示，而成本估算以任意單位表示;所以他們不太可能匹配。通常最重要的是要估計的行數是否合理地接近實際。

估計成本計算爲（磁盤頁面讀取* seq_page_cost）+（行掃描* cpu_tuple_cost）。默認情況下，seq_page_cost是1.0和cpu_tuple_cost爲0.01

來源

2016-09-15 17:50:42

瞭解Postgres的查詢計劃

回答

相關問題