libpq數據庫非常慢（2000萬條記錄）

我是SQL/RDBMS的新手。libpq數據庫非常慢（2000萬條記錄）

我有一個應用程序，它使用libpq庫在PostgreSQL服務器中添加10列的行。現在，我的服務器與我的visual C++應用程序在同一臺機器上運行。

我已經添加了大約15-20萬條記錄。使用select count(*) from <tableName>;獲取總數的簡單查詢需要4-5分鐘。

我用我輸入數據（時間碼）的時間索引了我的表格。大多數時候我需要添加不同的WHERE/AND條款。

有什麼辦法可以讓事情變得更快嗎？我需要儘可能快地做到這一點，因爲一旦服務器移動到網絡，事情將變得更慢。

謝謝

來源

2012-07-28 Garfield

什麼版本的Postgres你在嗎？ – Kuberchaun 2012-07-28 13:52:25

@garfield每當你[發佈一個問題]（http://stackoverflow.com/questions/11650018/libpq-code-to-create-list-and-delete-databases-c-vc-postgresql），有人問你爲您的PostgreSQL版本。這不是你提出問題時應該把它放進去嗎？ – 2012-07-28 14:50:24

硬件必須有問題。「count（*）」的5分鐘太長了。 – 2012-07-28 16:19:42

我不認爲網絡延遲將是您的查詢需要多長時間的一個重要因素。所有的處理都在PostgreSQL服務器上完成。

PostgreSQL MVCC設計意味着表格中的每一行（不僅僅是索引）必須被執行以計算計數（*），這是一項昂貴的操作。在你的情況下，涉及到很多行。

關於此主題有一個很好的維基頁面http://wiki.postgresql.org/wiki/Slow_Counting有建議。從這個鏈接

兩個建議，一個是使用一個索引列：

select count(index-col) from ...;

...雖然在某些情況下這僅適用。

如果你有一個以上的指標，看看哪一個都有用最少的成本：

EXPLAIN ANALYZE select count(index-col) from ...;

如果你可以用一個近似值生活，另一個是使用Postgres的特定功能像一個近似值：

select reltuples from pg_class where relname='mytable';

有多好這近似是取決於設置的頻率自動清理運行等諸多因素;看到評論。

來源

2012-07-28 12:08:37 pd40

但這可以幫助我獲取總表的數量。在表項中，我有一個順序增加長整數的列。總數將等於最後一行的那一列的值。這可以做很多優化。但是當我的查詢中添加「where」和「and」時，情況就會變得更糟。此外，如果我在「count（...）」中提供了列名，那麼postgre必須通過所有列來計算數量，它將如何產生影響。 – Garfield 2012-07-28 12:17:22

如果您的列被編入索引，PG將只需要對索引條目進行計數 - 而不是整個表格行。另外，放置where子句將限制行，並加快速度。試試看。您可以嘗試不同的索引+ EXPLAIN ANALYZE來查看它們的效果。 – pd40 2012-07-28 12:18:52

@Garfield當你說「按順序遞增長整數」時，你是指'SEQUENCE'還是'SERIAL' /'BIGSERIAL'？因爲他們可能有空隙或漏洞。即使您從未刪除過一行，最大ID也不一定等於行數。每當你做一個INSERT，然後回滾這個事務，你就會拋出生成的ID，留下一個洞。孔也可以以其他方式發生。 'max（id）'不是**與'serial（count）'是同一個事物。 – 2012-07-28 14:47:12

考慮pg_relation_size('tablename')並通過

select count(*) from tablename

花秒做這個表的完全掃描時，這將會給您的磁盤（S）的吞吐量將其分攤。如果它太低，你首先要專注於改善這一點。擁有良好的I/O子系統和良好的操作系統磁盤緩存對數據庫至關重要。

默認的postgres配置意味着不會消耗太多資源來與其他應用程序配合使用。根據您的硬件和機器的整體利用率，您可能需要調整幾個性能參數，如shared_buffers,effective_cache_size或work_mem。請參閱您的特定版本的文檔以及wiki的performance optimization頁面。

另請注意，select count(*)式查詢的速度與libpq或網絡無關，因爲只有一個結果行被檢索到。它完全發生在服務器端。

來源

2012-07-28 15:43:59

它也可以放緩表膨脹，所以要留意。確保autovacuum經常運行，如果你做了很多'更新'和'刪除'。 – 2012-07-29 02:17:39

您沒有說明您的數據是什麼，但通常情況下，處理大量數據的表的原因是對錶進行分區。 http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html

這不會加速您的select count(*) from <tableName>;查詢，甚至可能會減慢查詢速度，但如果您通常只對表中的部分數據感興趣，這可能會有幫助。

來源

2012-07-29 01:28:33

libpq數據庫非常慢（2000萬條記錄）

回答

相關問題