2012-03-02 51 views
1

我比較PostgreSQL 8.3.14上的查詢返回相同的結果集。如何準確測量查詢的效率?

我在查詢中使用了EXPLAIN來跟蹤估計的總成本。我也運行了幾次查詢並記錄了運行所花費的總時間。我知道連續運行會導致更多的數據被緩存,並扭曲實際的no-cache運行時。

我仍然認爲EXPLAIN的成本與總體運行時間有一定的比例(帶有緩存偏移)。

我的數據否認這一點。我比較了4個查詢。

  1. 查詢
    • 總成本:119 500
    • 平均運行時間:28.101秒
  2. 查詢乙
    • 總成本:115 700
    • 平均運行時間: 28.291秒
  3. 查詢Ç
    • 總成本:116 200
    • 平均運行時間:32.409秒
  4. 查詢d
    • 總成本:93 200
    • 平均運行時間:37.503秒

我最後運行了查詢D,如果有什麼,它應該是最快的,因爲緩存問題。由於運行查詢,而不緩存似乎在此基礎上Q + A到困難:

[SO]:See and clear Postgres caches/buffers?

如何衡量它的查詢是最有效的?

回答

1

規劃器顯示的查詢成本是你的索引結構的功能,並且也一定值的相關表格中的相對頻率。 PostgreSQL跟蹤所有表格中所有列的最常見值,以便了解每個計劃的每個階段可能運行多少行。

此信息可能會過時。如果您確實想知道查詢的成本如何,請通過執行VACUUM ANALYZE聲明確保postgres統計信息使用的是最新的。

除此之外,計劃者被迫做一些蘋果比較桔子;以某種方式比較尋找所花費的時間與在內存關係上運行緊密循環所花費的時間。由於不同的硬件可以以不同的相對速度完成這些工作,有時候,特別是對於近距離關係,postgres可能會猜錯。這些相對費用可以在server's config file

編輯的配置進行調整: 通過postgesql收集的統計數據不涉及「查詢性能」,而不是通過連續查詢更新。它們只描述每個表的每列中值的頻率和分佈(除非禁用)。準確的統計數據對於準確的查詢計劃非常重要,但它對您(運營商)告訴PostgreSQL的頻率和詳細程度應收集那些靜音。你所觀察到的差異是一個跡象,表明stastics過時了,或者你可以從調整其他計劃器參數中受益。

+0

文檔說'VACUUM ANALYZE [table]'將更新我包含的所有表的統計信息。在我看來,這會扭曲查詢比較,因爲每次連續運行都會有更好的統計數據。 – 2012-03-05 14:24:50

0

嘗試運行他們通過講解分析,並從輸出張貼到http://explain.depesz.com/

+0

但是,我這樣做並不能幫助我定量確定哪個查詢效率最高。它使查找問題區域更容易,但不能比較查詢效率。 – 2012-03-05 14:30:34