PostgreSQL 緩存

PostgreSQL physical storage 和 inter db    值得閱讀

數據在物理介質上存儲是以page的形式，大小爲8K，以下：

• a tuple或an item是行的同義詞
• a relation是表的同義詞
• a filenode是表示對錶或索引的引用的id。
• a block和page是等於它們表明存儲表的文件的8kb段信息。

PostgreSQL會把table數據和index以page的形式存儲在緩存中，同時在某些狀況下（使用 prepared）也會把查詢計劃緩存下來，可是不會去緩存具體的查詢結果。它是把查詢到的數據頁緩存起來，這個頁會包含連續的數據，即不單單是你所要的查詢的數據。

緩存指的是共享緩存，shared_buffers，所表明的內存區域能夠當作是一個以8KB的block爲單位的數組，即最小的分配單位是8KB。當Postgres想要從disk獲取(主要是table和index)數據(page)時，他會(根據page的元數據)先搜索shared_buffers，確認該page是否在shared_buffers中，若是存在，則直接命中，返回緩存的數據以免I/O。若是不存在，Postgres纔會經過I/O訪問disk獲取數據。

緩衝區的分配

咱們知道Postgres是基於進程工做的系統，即對於每個服務器的connection，Postgres主進程都會向操做系統fork一個新的子進程(backend)去提供服務。同時，Postgres自己除了主進程以外也會起一些輔助的進程。

所以，對於每個connection的數據請求，對應的後端進程(backend)都會首先向LRU cache中請求數據頁page(這個數據請求不必定指的是SQL直接查詢的表或者視圖的page，好比index和系統表)，這個時候就發起了一次緩衝區的分配請求。那麼，這個時候咱們就要抉擇了。若是要請求的block就在cache中，那最好，咱們"pinned"這個block，而且返回cache中的數據。所謂的"pinned"指的是增長這個block的"usage count"。

當"usage count"爲0時，咱們就認爲這個block沒用了，在後面cache滿的時候，它就該挪挪窩了。

那也就是說，只有當buffers/slots已滿的狀況下，纔會引起緩存區的換出操做。

緩存區的換出

決定哪一個page該從內存中換出並寫回到disk中，這是一個經典的計算機科學的問題。

一個最簡單的LRU算法在實際狀況下基本上很難work起來。由於LRU是要把最近最少使用的page換出去，可是咱們沒有記錄上次運行時的狀態。

所以，做爲一個折中和替代，咱們追蹤並記錄每一個page的"usage count"，在有須要時，將那些"usage count"爲0的page換出並寫回到disk中。後面也會提到，髒頁面也會被寫回disk。