為什麼並行 pg_restore 命令可能需要幾個小時才能完成其非並行等效命令？
我使用 pg_restore 使用以下命令從目錄備份中恢復了 50 GB 數據庫，該命令使用了 4 個作業：
pg_restore -d analytics -U postgres -j 4 -v "D:\Program Files\PostgreSQL\10\backups\Analytics_08_2018__7_53_21.36.compressed"我從命令行執行它。與非並行恢復相比，恢復耗時約**2 小時。**它似乎掛在還原作業結束時創建索引
pg_restore: launching item 2817 INDEX nidx_bigrams_inc_hits pg_restore: creating INDEX "public.nidx_bigrams_inc_hits" pg_restore: finished item 2965 TABLE DATA trigrams pg_restore: launching item 2822 INDEX nidx_trigrams_inc_hits pg_restore: creating INDEX "public.nidx_trigrams_inc_hits" pg_restore: finished item 2823 INDEX nidx_unigrams_inc_hits pg_restore: finished item 2822 INDEX nidx_trigrams_inc_hits pg_restore: finished item 2817 INDEX nidx_bigrams_inc_hits pg_restore: finished main parallel loop這些 pg_restore “創建索引”作業中的每一個在 pg_stat_activity 中都具有“空閒”狀態。另一個 pg_restore 作業在送出時是“空閒”的。
我希望並行恢復的完成速度比預設恢復快得多，而且它似乎一直在這樣做，直到它在大約 15 分鐘後掛在那裡。此伺服器上沒有發生太多其他事情。當我在作業完成之前檢查它們時，索引似乎是完整的，即它們與原始數據庫索引的大小相同。與非並行還原相比，並行還原作業需要更長的時間來完成/送出是否有任何特殊原因？如果我不能依賴工作持續時間，我想在災難恢復情況下為此做好準備並排除並行。
順便說一句，我知道基於文件系統的備份而不是邏輯備份，但我暫時只對邏輯感興趣。
這可能只是數據庫爭用。
進行並行轉儲，您的 postgres 可以一次寫入許多不同的文件，因此負載可以分散。
進行並行恢復時，postgres 必須管理所有這些
$$ heavy-weight $$來自作業+1 個連接的流量，全部填充緩衝區記憶體中的數據頁並將它們寫入磁碟，所有這些都一次完成。要創建索引，您需要重新讀取數據頁並掃描它們；一次對許多表執行此操作會給緩衝區記憶體帶來很大壓力…… postgres 需要做更多的工作。 此外，您已經指定了四個工作 - 您的數據庫是否
$$ server $$有足夠的 CPU / 核心來支持它嗎？如果不是這樣，那麼額外的作業仍然會啟動，但是會在作業系統級別受到爭用，因為它們會因為記憶體不足而被切換到$$ poor $$機器嘗試“同時”執行它們。在較小的伺服器上，您可能會得到$$ some $$從同時做兩份工作中受益，但不僅如此，而且成本很快就超過了收益。