postgresql資料庫體系結構
postgresql資料庫是由：連線管理系統（系統控制器）、編譯執行系統、儲存管理系統、事務系統、系統表 五大部分組成。
①：連線管理系統：接收外部操作對系統的請求，對操作請求進行預處理和分發，起系統邏輯控制作用。
②：編譯執行系統：由查詢編譯器、查詢執行器組成，完成操作請求在資料庫中的分析處理和轉化工作，最終實現物理儲存介質中資料的操作。
③：儲存管理系統：由索引管理器、記憶體管理器、外存管理器組成，負責儲存和管理物理資料，提供對編譯查詢系統的支援；
④：事務系統：是由事務管理器、日誌管理器、併發控制、鎖管理器組成，日誌管理器和事務管理器完成對操作請求處理的事務一致性支援，鎖管理器 和併發控制提供對併發訪問資料的一致性支援；
⑤：系統表：是postgresql資料庫的元資訊管理中心，包括資料庫物件資訊和資料庫管理控制資訊。系統表管理元資料資訊，將postgresql資料庫的各個模組有機地連線在一起，形成一個高效的資料管理系統。
1、系統表：
資料字典是關係資料庫系統管理控制資訊的核心，在postgresql資料庫系統中，系統表扮演著資料字典的角色。
系統表是postgresql資料庫存放結構元資料的地方，它在postgresql中表現為存放有系統資訊的普通表或者檢視。使用者可以刪除然後重建這些表、增加列、插入和更新數值，然而由使用者去修改系統會導致系統資訊的不一致性，進而導致系統控制絮亂。正常情況下不應該由使用者手工修改系統表，而是由sql命令關聯的系統表操作自動維護系統表資訊。
postgresql的每一個數據庫中都有自己的一套系統表，其中大多數系統表都是在資料庫建立時從模板資料庫中拷貝過來的，因此這些系統表裡的資料都是與所屬資料庫相關的。只有少數系統表是所有資料庫共享的（比如pg_database），這些系統表裡的資料是關於所有資料庫的。
由於系統表儲存了資料庫的所有元資料，所以系統執行時對系統表的訪問是非常頻繁的。為了提高系統性能，在記憶體中建立了共享的系統表cache，使用hash函式和hash表提高查詢效率。
主要系統表功能：
①：pg_namespace：
pg_namespace用於儲存名稱空間。名稱空間是sql92模式下層的結構：每個名字空間有獨立的關係、型別等集合，但並不會相互衝突。postgresql的名字空間層次是：資料庫、模式、表、屬性。
②：pg_tablespace：
pg_tablespace儲存表空間資訊，將表放置在不同的表空間有助於實施磁碟檔案佈局。pg_tablespace在整個資料簇裡只有一份，也就是說同一個資料集簇內的所有資料庫共享一個pg_tablespace表，而不是每個資料庫都有自己的pg_tablespace表。
③：pg_database：
pg_database中存放了當前資料集簇中資料庫的資訊，它也是一個在整個集簇範圍內共享的系統表。該表中每一個元祖就表示集簇中的一個數據庫，每一個數據庫都被分配一個OID作為唯一標識，並且儲存在對應元祖的隱藏屬性中。
④：pg_class：
pg_class儲存表及表類似結構的資料庫物件資訊，包含索引、序列、檢視、複合資料型別、toast表等。每一個物件都在pg_class中表示為一個元祖，並且每一個物件都會被分配一個OID作為唯一標識，該OID作為該元祖的一個隱藏屬性儲存。
⑤：pg_type：
pg_type儲存資料型別資訊。基本資料型別和列舉型別由create type建立，域型別由create domain建立，複合資料型別在表建立時自動建立。
⑥：pg_attribute：
pg_attribute儲存表的屬性資訊，對於資料庫中表的每個屬性都有一個元祖。
⑦：pg_index：
pg_index儲存索引的具體資訊。
系統檢視如下：
這些系統檢視提供了查詢系統表和訪問資料庫內部狀態的方法，如下大部分系統檢視及其用途：
pg_cursors ---開啟的遊標
pg_group ---資料庫使用者的組
pg_indexes ---索引
pg_locks ---當前持有的鎖
pg_prepared_statements --預備語句
2、資料集簇
postgresql安裝完成後，必須先使用initdb程式初始化磁碟上的資料儲存區，即資料集簇，由postgresql管理的使用者資料庫以及系統資料庫總稱為資料集簇。在postgresql的實現中，資料庫就是磁碟上一些檔案的集合，只不過這些檔案有特定的檔名、儲存位置等，並且有些檔案之間會相互關聯。預設情況下，postgresql的所有資料讀儲存在其資料目錄裡，這個資料目錄通常會用環境變數pgdata來引用。
pgdata中還儲存有資料集簇的配置檔案和其他子目錄，各個目錄及用途說明如下：
pg_version ：一個包含postgresql主版本號的檔案。
base目錄：包含每個資料庫目錄，資料庫目錄以資料庫的OID編號命名，其中名為1的目錄對應模板資料庫template1
global目錄：包含整個集簇共享的全域性表，比如pg_database
pg_clog目錄：包含事務提交狀態資料的子目錄
pg_multixact目錄：包含多重事務狀態資料的子目錄（用於共享的行鎖）
pg_stat_tmp目錄：包含統計子系統所需臨時檔案的子目錄。
pg_subtrans目錄：包含子事務狀態資料的子目錄。
pg_tblspc目錄：包含指向表空間的符合連結的子目錄。
pg_twophase目錄：包含用於預備事務的狀態檔案的子目錄
pg_xlog目錄：包含WAL（預寫日誌）檔案的子目錄。
postmaster.opts檔案：記錄伺服器上一次啟動時使用的命令列引數。
postmaster.pid檔案：一個鎖檔案，記錄著當前的守護程序postmaster的程序號和共享記憶體段ID，在伺服器關閉之後此檔案將被刪除。
postgresql.conf檔案：主要配置檔案，除基於主機的訪問控制和使用者名稱對映之外的其他使用者可設定引數都儲存在這個檔案中。
pg_hba.conf檔案：基於主機的訪問控制檔案，儲存對客戶端認證方式的設定資訊。
pg_indent.conf檔案：使用者名稱對映檔案，定義了作業系統系統使用者名稱和postgresql使用者名稱之間的對應關係，這些對應關係會被pg_hba.conf用到。
initdb的主要引數介紹：
-A method 指定本地連線的預設使用者認證方式。
-D datadir 資料目錄的路徑，必須是對當前使用者可讀寫的空目錄，也可以使用環境變數pgdata來指定
-E encodinc 指定預設資料庫編碼方式
-U name 指定資料庫超級使用者名稱
-W 指示超級使用者設定口令
-d 以除錯模式執行，可以打印出很多除錯資訊
-L 指定輸入檔案（比如postgres.bki）位置。
3、系統資料庫：
在初始化完成之後，會預設建立3個系統資料庫：template1，template0和postgres。其中template0和postgres都是在初始化過程中從template1拷貝過來的。
template1和template0 資料庫用於建立資料庫。postgresql中採用從模板資料庫複製的方式來建立新的資料庫，在建立資料庫的命令中可以用-T選項來指定以哪個資料庫為模板來建立新資料庫。
postgres用於給初始化使用者提供了一個可連線的資料庫，就像Linux系統中一個使用者的主目錄一樣。
注意：
這些系統資料庫都是可以刪除的，但是兩個模板資料庫在刪除之前必須將其在pg_database中元組的datistemplate屬性改為false，否則刪除時會提示“不能刪除一個模板資料庫”。
4、postgresql程序結構：
postgresql使用一種專用伺服器程序體系結構，其中，最主要的兩個程序就是守護程序postmaster和服務程序postgres。從本質上來說，postmaster和postgres都是通過載入postgres程式而形成的程序，只是在執行時所處的分支不同而已。守護程序postmaster負責整個系統的啟動和關閉。它監聽並接受客戶端的連線請求，為其分配服務程序postgres。服務程序postgres接受並執行客戶端傳送的命令。它在底層模組（如儲存、事務管理、索引等）之上呼叫各個主要功能模組（如編譯器、優化器、執行器等），完成客戶端的各種資料庫操作，並返回執行結果。
4.1、守護程序postmaster
它是一個執行在伺服器上的總控程序，負責整個系統的啟動和關閉，並且在服務程序出現錯誤時完成系統的恢復。它管理資料庫檔案、監聽並接受來自客戶端的連線請求，並且為客戶端連線請求fork一個postgres服務程序，來代表客戶端在資料庫上執行各種命令。同時postmaster還管理與資料庫執行相關的輔助程序。使用者可以使用postmaster、postgres或者pg_ctl命令啟動postmaster。
postmaster就像一個處理客戶端請求的排程中心。當客戶端程式需要對資料庫進行操作時，首先會發出一個起始訊息給postmaster進行請求。postmaster將根據這個起始訊息中的資訊對客戶端的身份進行驗證，如果身份驗證通過，postmaster就為該客戶端新建一個服務程序postgres。隨後postmaster將於客戶端的互動工作轉交給postgres服務程序，由postgres來完成客戶端所需要的資料庫操作。
postmaster也負責整個系統範圍的操作，例如：中斷等操作，postmaster本身不進行這些操作，它只是指派一個子程序在適當的時間去處理它們。同時它要在資料庫崩潰的時候重啟系統。postmaster程序在起始時會建立共享記憶體和訊號庫，postmaster及其子程序的通訊就通過共享記憶體和訊號來實現。這種多程序設計使得整個系統的穩定性更好，即使某個後臺程序崩潰也不會影響系統中其他程序的工作，postmaster只需要重置共享記憶體即可從單個後臺程序的崩潰中恢復。
4.1.1、輔助程序啟動：
在postgresql中，守護程序postmaster負責整個系統的啟動和關閉。在一個數據庫管理系統例項中，除了守護程序postmaster和服務程序postgres外，還包括一些其他後臺程序，用於專門負責某項具體的工作。在這些輔助程序出現問題時，postmaster程序重新產生出現問題的輔助程序。在postmaster的建立過程中會首先啟動syslogger日誌程序，並完成pgstat程序、autovacuum程序的初始化工作，而在postmaster的監聽迴圈中檢測輔助程序的狀態，並新建或者重新建立這些輔助程序。
①：syslogger輔助程序
postmaster程序呼叫syslogger_start函式啟動syslogger子程序。syslogger是8.0後新加的特性，它通過一個管道從postmaster、所有後臺程序及其他的子程序那裡收集所有的stderr輸出，並將這些輸出寫入到日誌檔案中。在postgresql.conf配置檔案中設定了日誌檔案的大小和存在時間，若當前的日誌檔案達到這些限制時，就會被關閉，並且一個新的日誌檔案會被建立。
②：輔助程序初始化
syslogger輔助程序啟動完成後，postmaster開始對輔助程序pgstat程序、autovacuum程序進行初始化操作，為程序分配必要的資源。
在pgstat程序的初始化過程中，主要完成用於傳送和接收統計訊息的UDP埠建立和測試，UDP埠的建立過程與前面描述的TCP埠建立流程相同，但是socket埠型別改為sock_dgram。
4.2、輔助程序：
postgresql的各個輔助程序完成特定的功能，支撐postgresql系統執行和管理工作。在postmaster程序中，為每個輔助程序設定了一個全域性變數來標識該程序號，分別為sysloggerPID、多個writerPID、walwriterPID、autovacPID、pgarchPID、pgstatPID。當這些變數值為0時，標識相應的程序尚未啟動。
4.2.1、syslogger系統日誌程序：
日誌資訊是資料庫管理員獲取資料庫系統執行狀態的有效手段。在syslogger的配置選項中可以設定日誌檔案的大小，syslogger會在日誌檔案達到指定大小時關閉當前日誌檔案，產生新的日誌檔案。在postgresql.conf配置檔案可以配置日誌操作的相關引數如下：
log_destination：配置日誌輸出目標，根據不同的執行平臺會設定不同的值，Linux下預設為stderr。
logging_collector：是否開啟日誌收集器，當設定on時啟動日誌功能，否則系統將不產生系統日誌輔助程序。
log_directory：配置日誌輸出資料夾。
log_filename：配置日誌檔名稱命名規則。
log_rotation_size：配置日誌檔案大小，當前日誌檔案達到這個大小時會被關閉，然後建立一個新的檔案來作為當前日誌檔案。
（當然，postgresql.conf中還提供了其他配置引數，可以根據需要進行設定。）
4.2.2、後臺寫程序bgwriter
BgWriter程序是把共享記憶體中的髒頁寫到磁碟上的程序。它的作用有兩個：一是定期把髒資料從記憶體緩衝區刷出到磁碟中，減少查詢時的阻塞；二是PG在定期作檢查點時需要把所有髒頁寫出到磁碟，通過BgWriter預先寫出一些髒頁，可以減少設定檢查點（CheckPoint，資料庫恢復技術的一種）時要進行的IO操作，使系統的IO負載趨向平穩。BgWriter是PostgreSQL 8.0以後新加的特性，它的機制可以通過postgresql.conf檔案中以"bgwriter_"開頭配置引數來控制：
bgwriter_delay:
backgroud writer程序連續兩次flush資料之間的時間的間隔。預設值是200，單位是毫秒。
bgwriter_lru_maxpages：
backgroud writer程序每次寫的最多資料量，預設值是100，單位buffers。如果髒資料量小於該數值時，寫操作全部由backgroud writer程序完成；反之，大於該值時，大於的部分將有server process程序完成。設定該值為0時表示禁用backgroud writer寫程序，完全有server process來完成；配置為-1時表示所有髒資料都由backgroud writer來完成。(這裡不包括checkpoint操作)
bgwriter_lru_multiplier：
這個引數表示每次往磁碟寫資料塊的數量，當然該值必須小於bgwriter_lru_maxpages。設定太小時需要寫入的髒資料量大於每次寫入的資料量，這樣剩餘需要寫入磁碟的工作需要server process程序來完成，將會降低效能；值配置太大說明寫入的髒資料量多於當時所需buffer的數量，方便了後面再次申請buffer工作，同時可能出現IO的浪費。該引數的預設值是2.0。
bgwriter的最大資料量計算方式：
1000/bgwriter_delay*bgwriter_lru_maxpages*8K=最大資料量
bgwriter_flush_after：
資料頁大小達到bgwriter_flush_after時觸發BgWriter，預設是512KB。
4.2.3、PgArch（歸檔）程序
類似於Oracle資料庫的ARCH歸檔程序，不同的是ARCH是吧redo log進行歸檔，PgArch是把WAL日誌進行歸檔。再深入點，WAL日誌會被迴圈使用，也就是說，過去的WAL日誌會被新產生的日誌覆蓋，PgArch程序就是為了在覆蓋前把WAL日誌備份出來。歸檔日誌的作用是為了資料庫能夠使用全量備份和備份後產生的歸檔日誌，從而讓資料庫回到過去的任一時間點。PG從8.X版本開始提供的PITR（Point-In-Time-Recovery）技術，就是運用的歸檔日誌。
PgArch程序通過postgresql.conf檔案中的如下引數進行配置：
# - Archiving -
#archive_mode = off # enables archiving; off, on, or always
# (change requires restart)
#archive_command = '' # command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0 # force a logfile segment switch after this
# number of seconds; 0 disables
archive_mode：表示是否進行歸檔操作，可選擇為off（關閉）、on（啟動）和always（總是開啟），預設值為off（關閉）。
archive_command：由管理員設定的用於歸檔WAL日誌的命令。在用於歸檔的命令中，預定義變數“%p”用來指代需要歸檔的WAL全路徑檔名，“%f”表示不帶路徑的檔名（這裡的路徑都是相對於當前工作目錄的路徑）。每個WAL段檔案歸檔時將呼叫archive_command所指定的命令。當歸檔命令返回0時，PostgreSQL就會認為檔案被成功歸檔，然後就會刪除或迴圈使用該WAL段檔案。否則，如果返回一個非零值，PostgreSQL會認為檔案沒有被成功歸檔，便會週期性地重試直到成功。
archive_timeout：表示歸檔週期，在超過該引數設定的時間時強制切換WAL段，預設值為0（表示禁用該功能）。4.2.4、PgStat（統計資料收集）程序：
PgStat程序是PostgreSQL資料庫的統計資訊收集器，用來收集資料庫執行期間的統計資訊，如表的增刪改次數，資料塊的個數，索引的變化等等。收集統計資訊主要是為了讓優化器做出正確的判斷，選擇最佳的執行計劃。postgresql.conf檔案中與PgStat程序相關的引數，如下：
#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------
# - Query/Index Statistics Collector -
#track_activities = on
#track_counts = on
#track_io_timing = off
#track_functions = none # none, pl, all
#track_activity_query_size = 1024 # (change requires restart)
#stats_temp_directory = 'pg_stat_tmp'
track_activities：表示是否對會話中當前執行的命令開啟統計資訊收集功能，該引數只對超級使用者和會話所有者可見，預設值為on（開啟）。
track_counts：表示是否對資料庫活動開啟統計資訊收集功能，由於在AutoVacuum自動清理程序中選擇清理的資料庫時，需要資料庫的統計資訊，因此該引數預設值為on。
track_io_timing：定時呼叫資料塊I/O，預設是off，因為設定為開啟狀態會反覆的呼叫資料庫時間，這給資料庫增加了很多開銷。只有超級使用者可以設定
track_functions：表示是否開啟函式的呼叫次數和呼叫耗時統計。
track_activity_query_size：設定用於跟蹤每一個活動會話的當前執行命令的位元組數，預設值為1024，只能在資料庫啟動後設置。
stats_temp_directory：統計資訊的臨時儲存路徑。路徑可以是相對路徑或者絕對路徑，引數預設為pg_stat_tmp，設定此引數可以減少資料庫的物理I/O，提高效能。此引數只能在postgresql.conf檔案或者伺服器命令列中修改。4.2.5、AutoVacuum（自動清理）程序
在PG資料庫中，對資料進行UPDATE或者DELETE操作後，資料庫不會立即刪除舊版本的資料，而是標記為刪除狀態。這是因為PG資料庫具有多版本的機制，如果這些舊版本的資料正在被另外的事務開啟，那麼暫時保留他們是很有必要的。當事務提交後，舊版本的資料已經沒有價值了，資料庫需要清理垃圾資料騰出空間，而清理工作就是AutoVacuum程序進行的。postgresql.conf檔案中與AutoVacuum程序相關的引數有：
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
# (change requires restart)
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
# before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit
autovacuum：是否啟動系統自動清理功能，預設值為on。
log_autovacuum_min_duration：這個引數用來記錄 autovacuum 的執行時間，當 autovaccum 的執行時間超過 log_autovacuum_min_duration引數設定時，則autovacuum資訊記錄到日誌裡，預設為 "-1", 表示不記錄。
autovacuum_max_workers：設定系統自動清理工作程序的最大數量。
autovacuum_naptime：設定兩次系統自動清理操作之間的間隔時間。
autovacuum_vacuum_threshold和autovacuum_analyze_threshold：設定當表上被更新的元組數的閾值超過這些閾值時分別需要執行vacuum和analyze。
autovacuum_vacuum_scale_factor和autovacuum_analyze_scale_factor：設定表大小的縮放係數。
autovacuum_freeze_max_age：設定需要強制對資料庫進行清理的XID上限值。
autovacuum_vacuum_cost_delay：當autovacuum程序即將執行時，對 vacuum 執行 cost 進行評估，如果超過 autovacuum_vacuum_cost_limit設定值 時，則延遲，這個延遲的時間即為 autovacuum_vacuum_cost_delay。如果值為 -1, 表示使用 vacuum_cost_delay 值，預設值為 20 ms。
autovacuum_vacuum_cost_limit：這個值為 autovacuum 程序的評估閥值, 預設為 -1, 表示使用 "vacuum_cost_limit " 值，如果在執行 autovacuum 程序期間評估的cost 超過 autovacuum_vacuum_cost_limit, 則 autovacuum 程序則會休眠。2.4.6、WalWriter（預寫式日誌寫）程序
預寫式日誌WAL（Write Ahead Log，也稱為Xlog）的中心思想是對資料檔案的修改必須是隻能發生在這些修改已經記錄到日誌之後，也就是先寫日誌後寫資料（日誌先行）。使用這種機制可以避免資料頻繁的寫入磁碟，可以減少磁碟I/O。資料庫在宕機重啟後可以運用這些WAL日誌來恢復資料庫。postgresql.conf檔案中與WalWriter程序相關的引數如下：
#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#wal_level = minimal # minimal, replica, or logical
# (change requires restart)
#fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
#synchronous_commit = on # synchronization level;
# off, local, remote_write, remote_apply, or on
#wal_sync_method = fsync # the default is the first option
# supported by the operating system:
# open_datasync
# fdatasync (default on Linux)
# fsync
# fsync_writethrough
# open_sync
#full_page_writes = on # recover from partial page writes
#wal_compression = off # enable compression of full-page writes
#wal_log_hints = off # also do full page writes of non-critical updates
# (change requires restart)
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
# (change requires restart)
#wal_writer_delay = 200ms # 1-10000 milliseconds
#wal_writer_flush_after = 1MB # measured in pages, 0 disables
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000
wal_level：控制wal儲存的級別。wal_level決定有多少資訊被寫入到WAL中。 預設值是最小的（minimal），其中只寫入從崩潰或立即關機中恢復的所需資訊。replica 增加 wal 歸檔資訊 同時包括 只讀伺服器需要的資訊。（9.6 中新增，將之前版本的 archive 和 hot_standby 合併）
logical 主要用於logical decoding 場景
fsync：該引數直接控制日誌是否先寫入磁碟。預設值是ON（先寫入），表示更新資料寫入磁碟時系統必須等待WAL的寫入完成。可以配置該引數為OFF，表示更新資料寫入磁碟完全不用等待WAL的寫入完成。
synchronous_commit：引數配置是否等待WAL完成後才返回給使用者事務的狀態資訊。預設值是ON，表明必須等待WAL完成後才返回事務狀態資訊；配置成OFF能夠更快地反饋回事務狀態。
wal_sync_method：WAL寫入磁碟的控制方式，預設值是fsync，可選用值包括open_datasync、fdatasync、fsync_writethrough、fsync、open_sync。open_datasync和open_sync分別表示在開啟WAL檔案時使用O_DSYNC和O_SYNC標誌；fdatasync和fsync分別表示在每次提交時呼叫fdatasync和fsync函式進行資料寫入，兩個函式都是把作業系統的磁碟快取寫回磁碟，但前者只寫入檔案的資料部分，而後者還會同步更新檔案的屬性；fsync_writethrough表示在每次提交併寫回磁碟會保證作業系統磁碟快取和記憶體中的內容一致。
full_page_writes：表明是否將整個page寫入WAL。
wal_buffers：用於存放WAL資料的記憶體空間大小，系統預設值是64K，該引數還受wal_writer_delay、commit_delay兩個引數的影響。
wal_writer_delay：WalWriter程序的寫間隔時間，預設值是200毫秒，如果時間過長可能造成WAL緩衝區的記憶體不足；時間過短將會引起WAL的不斷寫入， 增加磁碟I/O負擔。
wal_writer_flush_after：
commit_delay：表示一個已經提交的資料在WAL緩衝區中存放的時間，預設值是0毫秒，表示不用延遲；設定為非0值時事務執行commit後不會立即寫入WAL 中，而仍存放在WAL緩衝區中，等待WalWriter程序週期性地寫入磁碟。
commit_siblings：表示當一個事務發出提交請求時，如果資料庫中正在執行的事務數量大於commit_siblings值，則該事務將等待一段時間（commit_delay的值）；否則該事務則直接寫入WAL。系統預設值是5，該引數還決定了commit_delay的有效性。
wal_writer_flush_after：當髒資料超過閾值時，會被刷出到磁碟。2.4.7、CheckPoint（檢查點）程序
檢查點是系統設定的事務序列點，設定檢查點保證檢查點前的日誌資訊刷到磁碟中。postgresql.conf檔案中與之相關的引數有：
# - Checkpoints -
#checkpoint_timeout = 5min # range 30s-1d
#max_wal_size = 1GB
#min_wal_size = 80MB
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB # measured in pages, 0 disables
#checkpoint_warning = 30s # 0 disables©著作權歸作者所有：來自51CTO部落格作者一個笨小孩的原創作品