AWS Aurora PostgreSQL Serverless：如何在擴展後預熱共享緩衝區？

我正在使用AWS Aurora PostgreSQL Serverless自動縮放。看起來好像縮放清除了共享緩衝區，所以當我們想要提高性能時，我們不得不面對 I/O 瓶頸。熱身後，我們看到了巨大的性能提升。但是，如果我們在縮放後背靠背執行，第二次執行會更快。雖然我還沒有看到任何關於共享緩衝區是否在縮放時被清除的具體資訊，但我幾乎可以肯定它是。

目前正在使用 Aurora Serverless PostgreSQL 10.14，它支持pg_prewarm擴展。看起來最新的文件表明 prewarm 支持在伺服器重新啟動後自動預熱，但這是無伺服器的，並且在文件中似乎沒有提到自動預熱的版本。

我發現這篇文章在重新啟動伺服器或從崩潰中恢復時非常適合 PostgreSQL。

1. 如果我們至少可以在縮放後保留較低 ACU 節點的共享緩衝區的內容，那很好。
2. 如果我們可以提前準確地預熱需要在記憶體中的內容，那就太棒了！
3. 有些桌子很大，我們希望有選擇地預熱我們想要的部分。 pg_prewarm支持first_block和last_block阻止表/索引的數字，但是如何知道要在其中放入什麼值？

我們提前知道我們的高峰是什麼時候，並在之前告訴 RDS 進行擴展，這樣我們就有了一個可以準備的時間視窗。

我有哪些選擇？

我的回答不是針對 AWS Aurora PostgreSQL Serverless，而是針對一般的 Postgres。

簡單的替代方案

在您的相關評論中，您暗示您只需要過去 24 小時內的行。所以你可以（不涉及 pg_prewarm）簡單地：

SELECT * FROM public.tbl WHERE created_at > now() - interval '24h';

如果created_at被索引，並且謂詞具有足夠的選擇性，則表和索引的相關塊被預熱。

由於您實際上不想在預熱時檢索任何數據，因此您可以PERFORM在DO語句中使用：

DO
$$BEGIN
  PERFORM * FROM public.tbl WHERE created_at > now() - interval '24h';
END$$;

一樣的效果。

您可以通過以下方式驗證成功EXPLAIN (ANALYZE, BUFFERS)：

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM public.tbl WHERE created_at > now() - interval '24h';

如果有足夠的記憶體記憶體可用，您現在應該只能看到“共享命中”緩衝區。像：

Buffers: shared hit=123456

..你會看到大部分是“讀取”，大部分是冷記憶體。像：

Buffers: shared hit=143 read=153689

基本上，只需執行預期的查詢，記憶體就會相應地填充。

pg_prewarm()

如果您仍想使用pg_prewarm()塊編號，您也可以這樣做。允許更多選項，例如選擇要填充的記憶體（作業系統或數據庫緩衝區記憶體）或其他一些技巧。必須首先安裝附加模組，每個數據庫一次：

CREATE EXTENSION pg_prewarm;

僅當您的表（大部分）物理聚集在假定的列上時，使用塊號才有意義created_at。只讀（主要讀取）表就是這種情況，其中具有目前時間戳的新行附加在表的末尾。

您可以從其獲取行的塊號**ctid**。看：

• 如何將 ctid 分解為頁碼和行號？

要獲取小於 24 小時的第一行的塊號：

SELECT ctid
FROM   public.tbl
WHERE  created_at > now() - interval '24h'
ORDER  BY created_at
LIMIT  1;

你得到類似的東西(5759,1)。5759是塊號。那麼你就可以：

SELECT pg_prewarm('public.tbl'::regclass, first_block => 5759)

由於我們last_block將其保留為預設值NULL，因此“通過關係中的最後一個塊”的所有內容都將被預熱。（不過，不是索引。你也可以預熱它。）

函式呼叫使用“混合表示法”（“位置”和“命名表示法”的混合）。看：

• 具有可變數量輸入參數的函式

引用自：https://dba.stackexchange.com/questions/295140