hexdump -C 數據表文件 -- 查看表文件中數據。
pg_stat_statements
pgcompacttable -- 在減少鎖的情況下,清理表和索引的老空間。
pg_reorg功能類似於vacuum full和cluster,但是它在執行過程中不產生鎖,不會阻礙select和dml,在數據庫維護過程中可以祈禱非常大的作用.
pg_repack--PostgreSQL中的表可能會由於MVCC特性而導致碎片化和膨脹,或者是因為大量的行被刪除。這不僅會導致表中的空閑空間被占用,而且還會導致執行的sql語句效率不高。pg_repack
是通過最流行的重新組織和打包表的辦法來解決這個問題
pg_squeeze 表收縮插件:pg_squeeze is an open source PostgreSQL extension that enables automatic and transparent fixing of bloated tables https://www.cybertec-postgresql.com/en/products/pg_squeeze/
pgaudit--PostgreSQL有一個基礎的語句日志功能。它可以設置log_statement =all參數來使用標准日志記錄工具來實現。但這不足以滿足大多數審計要求。企業部署的數據庫特性之一就是針對用戶交互/語句進行細粒度審計的功能。這是許多安全標准主要的遵從要求。PostgreSQL審計擴展(pgaudit
)通過標准的 PostgreSQL日志記錄工具提供詳細的會話或對象審計日志記錄。
pldebugger--對於使用PL/pgSQL編寫存儲過程的開發人員來說,這是一個必要的擴展。
plprofiler--這是一個很好的擴展,可以找到執行慢的代碼位置。這是非常有用的,特別是在專用數據庫(如Oracle到 PostgreSQL)的復雜遷移過程中,會影響應用程序的性能。這個擴展可以編寫一份關於總體執行時間和表狀態的報告,並提供每一行代碼的清晰信息。這個擴展在PGDG repo中是不可用,需要從源碼中構建它。
cstore_fdw-- PostgreSQL的列式存儲擴展。
HypoPG--HypoPG
是一個支持添加虛擬索引的擴展--也就是說,不實際添加索引。這有助於我們回答例如“如果x列上有索引,執行計划將會怎樣”等問題。
orafce--實現了Oracle數據庫中的一些功能。該功能在Oracle10g上得到了驗證,該模塊對於生產工作非常有用。
TimescaleDB--在這個IOT和互聯設備的新世界中。對於時序數據需求越來越大。timescale
可以將 PostgreSQL轉換為可擴展時序數據進行存儲。
pg_bulkload --將大量數據以非常高效和快速的方式加載到數據庫中對您來說是一個挑戰嗎?如果這樣的話,pg_bulkload
可能會幫助你解決這個問題。
pg_pathman-- PostgreSQL10引入了分區。但是創建新的分區和維護現有分區,包括清除不需要的分區時需要手工操作,如果你想使用自動化的部分維護,可以看看pg_partman
提供了什么功能。
wal2json--PostgreSQL具有與邏輯復制相關的內置特性,另外的信息被記錄在WAL中,這將有助於邏輯解碼。wal2json
是一個流行的邏輯解碼輸出插件。還可以用於不同的用途,包括變化數據捕獲。除了wal2json
之外還有其他輸出插件:PostgreSQL wiki中有一個簡明的列表。
巡檢類工具:
pgmetrics,GO寫的一款PostgreSQL 多版本、健康監控指標采集、報告開源軟件。https://github.com/rapidloop/pgmetrics
結合pgdash,可以實現被監控PG實例的可視化,指標值變更告警等。https://pgdash.io/
實時top類工具:
pg_center:Command-line admin tool for observing and troubleshooting Postgres.
pg_top:pg_top is 'top' for PostgreSQL. It is derived from Unix Top. Similar to top, pg_top allows you to monitor PostgreSQL processes.
pgfincore:將文件緩存到內存中
pgwarm:預熱,兩個差不多
pg_prewarm 集成於 contrib pgfincore:https://github.com/klando/pgfincore 1)pgfincore 主要是利用 POSIX 的 posix_fadvise函數,pgfadvise_loader_file中可以看到它的調用,支持兩種模式:POSIX_FADV_WILLNEED與POSIX_FADV_DONTNEED,posix_fadvise詳細解釋請看:http://linux.die.net/man/2/posix_fadvise。 文檔沒有提到 WILLNEED 會持續多久,影響范圍多大,恐怕需要我們去讀一下源代碼才能更清楚。 看名字就知道,這個函數只是建議 OS 怎么做,最終還得OS說了算。 2)pg_prewarm 直接看利用系統緩存的代碼,簡單粗暴,但是最終哪些塊能留住恐怕就不好說了。 並不是每個系統都支持 posix_fadvise,這時候 pg_prewarm 就會成為唯一選擇。 可以看出,利用操作系統緩存來預熱PG數據,都有一定的不可控性,並不能干涉最底層的動作,都是發出建議。
pg_systat
https://github.com/pg-systat/pg_systat
pg_proctab
https://github.com/markwkm/pg_proctab
pgdash
https://github.com/rapidloop/pgdash
https://github.com/darold/pgbadger
pgcluu
https://github.com/darold/pgcluu
pg_buffercache
https://www.postgresql.org/docs/10/pgbuffercache.html
http://blog.sina.com.cn/s/blog_544a710b0101betd.html
------------------------未完待續-------------------
pgtune:在線參數推薦:
2020-05-04:
索引推薦:
pg_qualstats
2020-06-29: