在學習PostgreSQL的過程中，很容易陷入一種情況，貌似都懂，一問就含糊，今天我就來捋一捋那團亂麻。

postgresql 啟動源于守護進程，其功能強大，主管比如執行恢復、初始化共享數據結構/內存空間，以及啟動強制和可選的進程。

PostgreSql 在啟動后，就開始接受客戶的訪問，下圖演示了一個客戶如何申請連接，由守護進程來分配一個子進程，然后來服務于客戶的方式。

當有成千上萬的用戶要讀取數據庫中的數據，并且想更高速度度的讀取，那就會牽扯到PG中的內存系統，PG的內存系統中，客戶與backend process來進行交互，而backend process 會與PG的共享buffer中，而與其他數據庫不同的地方是，PG的內存并不會和其他的三家的數據庫一樣，他要求的本身的buffer 的設置不會特別大(相對于其他三家的)，他的設計中還要利用LINUX 系統的緩沖系統，在數據的讀取上并不會引起任何問題，速度上也會有保障。

除了這兩種級別的緩存之外，我們還可以使用磁盤控制器緩存、磁盤驅動器緩存等等。

上面基本上在關注與數據庫的讀操作，關于寫操作中的一個問題就是大量數據的更改插入，數據是否馬上會進行刷盤用戶對表數據進行大量更改并發提交的情況下，不會馬上對底層數據文件執行寫操作。這可能只會導致確保提前寫日志(WAL)文件與WAL緩沖區保持同步。那怎么來保證事務的持久性的問題和事務的原子性的問題，WAL 日志的重要的作用就是，保證系統的高性能下的AD功能，并讓數據最終一致在數據文件中。

通過 buffercache 和 oid2name 兩個命令可以看到目前的數據庫的buffer到底有那些數據庫已經在內存中。

當然如果想關心一下，用戶表的buffer讀取的數據塊的浮動可以將上的查詢保存在一個表里面，并輔以時間，這樣你就可以繪制出一個用戶表的burfer的周期表。(能干什么自己想想，很有意思的)

SELECT  
c.relname,  
count(*) AS buffers  
FROM pg_class c  
JOIN pg_buffercache b  
ON b.relfilenode=c.relfilenode  
INNER JOIN pg_database d  
ON (b.reldatabase=d.oid AND d.datname=current_database())  
WHERE c.relname NOT LIKE 'pg%' GROUP BY c.relname ORDER BY 2 DES 

然后我們就到了內存與磁盤的交換，checkpoint，如

數據在內存中也不能一直寄存，需要落盤，這就牽扯到下一步checkpoint，檢查點，檢查點是一個強制的過程，在PG中數據總是以數據塊寫入和讀取的，無論這個塊的數據是否占滿8K，讀取的時候也是以塊為單位進行讀取，

用戶在緩沖區中進行了更改，緩沖區與物理磁盤的數據文件不一致，該緩沖區的數據就是臟的，checkpoint的作用就是要將這些已經確認改變的數據寫入到數據的文件的過程。相關的所有的數據頁和索引頁都會進行更新，同時將這個頁面標記OK。

這樣的方式可以讓HEAP PAGE 和 INDEX PAGE 在這個checkpoint之前的頁面都刷到磁盤的數據文件中。那么我可以理解的是，如果此時數據庫沒有任何的其他的手段，此時斷電，那CHECKPOINT 之后的數據就會丟失(實際情況當然不會)，這也就是redo，重做日志要檢查checkpoint點的問題，他要確定從哪里開始重做

checkpoint 有三個參數，checkpoint_segments, checkpoint_timeout, 和checkpoint_completion_target.(PG 9X)

三個參數前兩個屬于湊夠多少wal 才開始 checkpoint, 如果這個長時間沒有checkpoint 那就根據第二個參數 checkpint_timeout 來根據時間來進行checkpoint，當然這樣做的后果是，如果某個階段數據量比較大，I/O就會出現消耗較高的情況，那第三個參數，checkpoint_completion_target就啟動作用，讓這個突發的情況，稍微的緩解，拉長這個寫入的時間，讓I/O系統不會那么的忙。

而當前PG11 中的與checkpoint的有關的參數不在有checkpoint_segments，換來的是max_wal_size ，要不超過設定時間去checkpoint 要不就是超過 max-wal-size 來進行 checkpoint，感覺這樣設置比較合理，如果使用上面的方法，其實使用一個函數，就可以讓PG的checkpoint紊亂，甚至可能會宕機(使壞的方法是就算了)

最后要在wal log 里面結束此次的捋一捋的活動。當我們對數據進行更改時，不會立即將更改寫入數據文件，對緩沖區中的塊進行更改，并將這些更改的記錄寫入WAL緩沖區，所以wal 才是保證系統運行效率與數據安全之間的一個妥協的產品。

select * from pg_walfile_name(pg_current_wal_lsn()); 

如何知道當前你正在操作的那個 wal 日志。(PG11)

SELECT pg_xlogfile_name(pg_current_xlog_location()); (PG 9X) 

使用過PG的人都知道PG 沒有 DOUBLE WRITE 這個功能其實(DW是那個數據庫的特征就不在說了)，FULL PAGE 來支持的，到底FULL PAGE 是用了什么方法，躲避了 DW ，保證了數據的完全。當然這也是要消耗系統的I/O性能的，同時也可以通過細調某些參數來緩解某些性能問題。

在這之前我們說說為什么會有這樣的情況，數據頁如果是8KB的情況下，那硬件和系統能一次將這些信息都寫到磁盤， 答案當然是 不 不 不

LINUX 一次是 4KB ，那硬件系統就更不知道是 4KB 還是 8KB ，所以如果系統CRASH 了，怎么辦你明明寫了8KB 人家寫了 4KB 就斷了，剩下了4KB 找誰，丟了，那啟動后，物理頁面損壞，誰給修，你給修。所以不同的數據庫就各顯神通，要把這塊給彌補了。

PG 這里就是 FULL PAGE 主要是操作的是將PostgreSQL服務器會在檢查點后第一次修改該頁時將每個磁盤頁的全部內容寫入WAL。這樣的好處是如果在下一次checkpoint的之前幾期crash了，則我們在WAL 中有所有的數據頁面，通過這些數據頁面就可以將數據恢復。不好的地方就是將數據寫入到了WAL日志中，多寫數據是一定要影響性能的。

這里如果我們提高checkpoint的頻率，會從邏輯的角度來抵消FULL page的影響，而如果縮小checkpoint的頻率，那可能就會人為的創造出一個大的突發寫入，那上邊的一個參數就的調整了，那個參數呢，我想你已經知道了。

但結果是我不會關閉FULL PAGE 因為性能與數據的安全性比較，那個應該優先，不言而喻。

以上內容由東方瑞通資深講師 Austin供稿，13年專業DBA經驗，曾任互聯網金融公司Senior DBA、500強制藥企業Senior DBA，精通Mysql、PostgreSQL、Mongo DB、SQLServer。