PostgreSQL解釋：爲什麼孩子比父母有更大的成本？

爲什麼一些較低規劃節點的成本高於最頂層節點的成本？在this article，我發現這個例子PostgreSQL解釋：爲什麼孩子比父母有更大的成本？

EXPLAIN SELECT * 
FROM tenk1 t1, onek t2 
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; 

             QUERY PLAN 
------------------------------------------------------------------------------------------ 
Merge Join (cost=198.11..268.19 rows=10 width=488) 
    Merge Cond: (t1.unique2 = t2.unique2) 
    -> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244) 
     Filter: (unique1 < 100) 
    -> Sort (cost=197.83..200.33 rows=1000 width=244) 
     Sort Key: t2.unique2 
     -> Seq Scan on onek t2 (cost=0.00..148.00 rows=1000 width=244)

子節點索引掃描比合並連接節點的較大成本。在文章中還指出：「瞭解上層節點的成本包括其所有子節點的成本是很重要的」。

那麼，爲什麼孩子的成本比父母高呢？

來源

2015-03-24 ethanjyx

注意'explain'只會給你一個_estimate_。如果您運行'explain（analyze，verbose）'，那麼它會爲您提供_real_成本和行數。您可能想要將這些與估算值進行比較。 – 2015-03-25 07:22:01

即使這是估計，父母如何估計成本比孩子少？估算算法不會自動增加兒童成本？ – ethanjyx 2015-03-25 18:16:09

它看起來像是一個錯誤，或者在文檔中的示例被調整用於顯示目的，這是不正確的修改。正如文檔所述，我能想到的唯一情況是子成本的總和可以超過父項，其中操作被LIMIT子句部分中止。 – 2015-03-25 18:56:05

正如你看到的成本確實包括所有兒童的成本:) 和兒童索引的行可能會超過你加入查詢的結果。因此，如果tenk1_unique2是unique2和其他值上的複合唯一鍵，並且是此連接的最便宜索引，則它可以保存具有一個唯一2值的101行...這樣，您可以將101與1進行比較，並獲得1行結果。 ...

更新1 父母的成本是兒童成本的總和。但連接中的小孩的行號更大。但是如果你對101加入1，你會得到1。所以家長可以有1列，而孩子100行...

UPDATE2我想sentense

的上層節點的開銷包括它的所有子節點的成本

只適用於

預計的啓動成本

UPDATE3

和我的同事說，估計總成本（656.28）應用過濾器之前來... ...

來源

2015-03-25 07:09:30

嗨，謝謝你的回覆。我不明白你的答案，你可以重新修改一下嗎？ – ethanjyx 2015-03-25 18:15:18

@ethanjyx兒童成本不算大。它是更大的行。簡而言之，這就是答案。其餘的都是可能原因的例子...... – 2015-03-26 13:18:12

PostgreSQL解釋：爲什麼孩子比父母有更大的成本？

回答

相關問題