# 54.6\. 索引開銷估計函數 系統給`amcostestimate` 一些描述可能的索引掃描的信息，包括一個 WHERE 子句和 ORDER BY 子句的列表，這個子句列表是系統認為可以被索引使用的東西。 它必須返回訪問該索引的開銷估計值以及 WHERE 子句的選擇性(也就是說，在索引掃描期間檢索的將被返回的數據行在父表中所占據的比例)。 對于簡單的場合，幾乎開銷估計器的所有工作都可以通過調用優化器里面的標準過程完成； 有`amcostestimate`這個函數的目的是允許索引訪問方法提供和索引類型相關的知識，這樣也許可以改進標準的開銷估計。 每個`amcostestimate`函數都必須有下面這樣的簽名： ``` void amcostestimate (PlannerInfo *root, IndexPath *path, double loop_count, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation); ``` 頭3個參數是輸入： `root` 規劃器的有關正在被處理的查詢的信息。 `path` 被考慮的索引訪問路徑。除了開銷和選擇性其他所有的域都是有效的。 `loop_count` 索引掃描的重復次數，這個應該被考慮到開銷估算中。 當考慮到用于嵌套循環內部的參數化掃描時，通常它大于1。 注意開銷估算仍然只是為了一次掃描；一個大的`loop_count`的意思在多次掃描間進行某些緩存可能是合適的。 后面四個參數是傳遞引用的輸出： `*indexStartupCost` 設置為索引啟動處理的開銷 `*indexTotalCost` 設置為索引處理的總開銷 `*indexSelectivity` 設置為索引的選擇性 `*indexCorrelation` 設置為索引掃描順序和下層的表的順序之間的相關有效性 請注意開銷估計函數必須用 C 寫，而不能用 SQL 或者任何可用的存儲過程語言，因為它們必須訪問規劃器/優化器的內部數據結構。 索引訪問開銷應該以`src/backend/optimizer/path/costsize.c` 使用的單位進行計算：一個順序磁盤塊抓取開銷是`seq_page_cost`， 一個非順序抓取開銷是`random_page_cost`， 而處理一個索引行的開銷通常應該是`cpu_index_tuple_cost`。 另外，在任何索引處理期間調用的比較操作符，都應該增加一個數量為`cpu_operator_cost` 倍數的開銷(特別是計算索引條件 indexquals 自己的時候)。 訪問開銷應該包括所有與掃描索引本身相關的磁盤和 CPU 開銷，但是_不包括_檢索或者處理索引標識出來的父表的行的開銷。 "啟動開銷"是總掃描開銷中的這樣一部分：在開始抓取第一行之前，必須花掉的開銷。 對于大多數索引，這個可以是零，但是那些啟動開銷很大的索引類型可能不能把它設置為零。 `indexSelectivity`應該設置成在索引掃描期間，父表中的行被選出來的部分的百分比。 在有損耗的查詢的情況下，這個值通常比實際通過給出的查詢條件的行所占的百分比要高。 `indexCorrelation`應該設置成索引順序和表順序之間的相關性(范圍在 -1.0 到 1.0 之間)。 這個數值用于調整從父表中抓取行的開銷估計。 當`loop_count`大于1，返回的數值應當在每一次索引掃描之間平均。 **開銷估計** 一個典型的開銷估計器會像下面這樣進行處理： 1. 基于給出的查詢條件，估計并返回父表中將被訪問的行的百分比。 如果缺乏索引類型相關的知識，那么使用標準的優化器函數`clauselist_selectivity()`: ``` *indexSelectivity = clauselist_selectivity(root, path->indexquals, path->indexinfo->rel->relid, JOIN_INNER, NULL); ``` 2. 估計在掃描過程中將被訪問的索引行數。對于許多索引類型，這個等于`indexSelectivity`乘以索引中的行數，但是可能更多。 （請注意，索引的總頁面數和行數可以從`path->indexinfo`結構中獲得。） 3. 估計在掃描中將取出的索引頁面數量。這個可能就是`indexSelectivity`乘以索引的總頁面數。 4. 計算索引訪問開銷。一個通用的估計器可以這么干： ``` /* * Our generic assumption is that the index pages will be read * sequentially, so they cost seq_page_cost each, not random_page_cost. * Also, we charge for evaluation of the indexquals at each index row. * All the costs are assumed to be paid incrementally during the scan. */ cost_qual_eval(&index_qual_cost, path->indexquals, root); *indexStartupCost = index_qual_cost.startup; *indexTotalCost = seq_page_cost * numIndexPages + (cpu_index_tuple_cost + index_qual_cost.per_tuple) * numIndexTuples; ``` 不過，上面沒有考慮多次重復索引掃描中索引讀取的開銷分攤。 5. 估計索引的相關性。對于簡單的在單個字段上的有序索引，這個值可以從 pg_statistic 中檢索。 如果相關性是未知，那么保守的估計是零(沒有相關性)。 開銷估計器函數的例子可以在`src/backend/utils/adt/selfuncs.c`里面找到。