PostgreSQL 物理檔案對映解析

    我們知道，在PG中，每個relation，也就是表，都有好幾個fork對應。存放主表資料的為“MAIN” fork；管理空餘空間的為“FSM” fork；存放視覺化檢視的為“visibility” fork。

那麼PG又是如何將每個表的fork管理起來，並跟pg_class中的relfileno對應起來的呢？這可以分為兩類：一類是常規表；一類是系統表。

 

1.常規表

    假設我有一張表叫”tab_mvcc_test”，它在postgres資料庫中。因此我們得先找到資料庫目錄。查pg_database，得到oid為“12896”。

接著去base目錄下，找到相應的資料庫目錄。“12896”目錄就是我們想要的。

 

然後從pg_class中，我們查到”tab_mvcc_test”的relfilenode為“16483”。

接著我們進入資料庫目錄“12896”，然後list一把，提到以下相關的三個檔案。以“_fsm”字尾的就是Free Space Mapping檔案。以”vm”字尾的就是visibility map。

而沒有字尾的那個就是我們的主表資料檔案，裡面還存放了索引資料。

 

2.系統表

    另外像系統的catalog表，如pg_class，它的refileno是”0“,又是什麼原因呢？PG對於系統表處理，不能像常規表一樣。這就有點類似於”雞生蛋，還是蛋生雞“。因為系統表是來管理常規表的。

PG對於這些catalog表，放到一個檔案中去管理，將oid與relfileno做對映。這個檔案就是著名的”pg_filenode.map“。這個檔案的大小為512，剛好是一個OS disk sector的大小。

PG做了對齊處理，在原始碼上用RelMapFile結構體與之對應。結構體大小為：62*8+4*4=496+16=512。也就是說這個檔案最多存放62條系統catalog表的記錄。

由於這個檔案的重要性，剛好與disk sector大小對齊，減少檔案crash的機率。

我們接下來把pg_filenode.map DUMP出來看一下，裡面是什麼資料：

第一個圈中的資料為PG檔案頭的魔法資料字，那麼第二個圈中的，到底對應的是哪個catalog表呢？我們可以計算下:“4eb”對應十進位制資料就是”1259“，剛好是pg_class的oid。

而後面的”3172”對應的就是12658。剛好是relfilenode。完美的對應了起來。

再得到檔案如下：

記錄數剛好14，跟上面圖中兩個紅色圈之間的數字”000e“對起來。這個檔案還存放了這些系統表對應的索引檔案filenode。