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