PostgreSQL順序掃描小表緩慢

我在PostgreSQL中有一張表，我需要讀入內存。這是一張非常小的桌子，只有三列和200排，我只做了一件select col1, col2, col3 from my_table。PostgreSQL順序掃描小表緩慢

在開發機器上，這是非常快的（小於1ms），即使該機器是Mac OS FileVault內的VirtualBox。

但是在生產服務器上它一直需要600毫秒。生產服務器可能具有較低的規格，數據庫版本也較舊（7.3.x），但我認爲，單靠這一點無法解釋這種巨大差異。

在這兩種情況下，我都在db服務器上運行explain analyze，所以它不能成爲網絡開銷。查詢執行計劃在這兩種情況下都是簡單的順序全表掃描。當時在生產機器上也沒有其他任何事情發生，因此爭用也沒有了。

怎樣才能找出爲什麼這是如此之慢，我能做些什麼呢？

來源

2009-12-22 Thilo

升級儘快 - 7.3不正式支持。 – 2009-12-22 13:43:03

聽起來像也許你沒有正確地使這個數據庫真空？ 7.3是的方式太老了，沒有AutoVacuum，所以這是你必須手動做的事情（建議使用cron作業）。如果你已經有很多更新（隨着時間的推移）到這個表，並且不運行VACUUM，它將很慢訪問。

來源

2009-12-22 11:23:33

我可以在VACUUM上次完成時瞭解嗎？ – Thilo 2009-12-22 11:28:28

@Thilo：在7.3 - 你很可能找不到。 – 2009-12-22 11:50:47

雖然沒有真正的好方法，但您可以做的一件事就是比較磁盤上表格文件的大小（檢查pg_class中的relfilenode以查找文件名）與您認爲應在表格中的數據量。如果沒有辦法，你需要在桌上運行VACUUM FULL和REINDEX。哦，和其他許多人說的一樣，升級到支持的Postgres版本。 – 2009-12-22 20:57:27

如果您多次運行查詢會發生什麼？ fisrt運行速度應該很慢，但其他速度應該更快，因爲第一次執行會將數據放入緩存中。

順便說一句：如果你做一個SELECT ... FROM沒有任何限制，你有一個seq掃描是100％正常的，你必須seq掃描檢索值，並且由於你有限制，沒有需要做一個索引掃描。

不要猶豫，發佈您的解釋分析查詢的結果。

PostgreSQL 7.3真的很舊，沒有選擇升級到更新的版本？

來源

2009-12-22 11:06:29 chburd

第二次沒有變得更快。順序掃描沒有問題，因爲這將是讀取整個表格的理想訪問路徑。我只想讓掃描花費更少的時間... – Thilo 2009-12-22 11:23:48

這顯然是表膨脹。對有問題的表進行真空分析。另外 - 升級。 7.3甚至不再支持。

來源

2009-12-22 11:50:06

VACUUM似乎是點亮的。我必須要求操作人員這樣做。只是爲了確認桌子會大量縮小，我怎麼能看到它現在佔據了多少塊？然後，我可以將其與我的開發機器上所具有的內容進行比較。 – Thilo 2009-12-22 11:57:47

它會*不*縮小。它可能會縮小一些，但我不會真正考慮它。 – 2009-12-22 20:32:03

如果它不縮小VACUUM做什麼？ – Thilo 2009-12-23 05:43:01

PostgreSQL順序掃描小表緩慢

回答

相關問題