1.什麼樣的場景，推薦PG？（PG最不擅長的在哪個方面，最擅長的在哪個方面？）
OLTP場景，複雜SQL場景，單庫資料量小于1TB,SQL層資料分析（GreenPlum），GIS需求場景，資料庫全文索引方案，Oracle遷移場景，對接外部多資料源FDW場景等。
不擅長的方面：偏網際網路場景簡單大并發，大量連接配接，主要問題是後端程序間内部溝通成本太高，是以需要使用連接配接池。
| 場景 | 場景分析 |
| 大量插入，少量修改 | 非常适合，放心使用 |
| 并發量不大，大量DML非7*24場景 | 非常适合，每天有維護視窗進行vacuum |
| 并發量較大，大量DML非7*24場景 | 非常适合，每天有維護視窗進行vacuum |
| 并發量不大，大量DML7*24場景，存在較為空閑維護視窗 | 适合，定期在非業務高峰期進行vacuum |
| 并發量較大，大量DML7*24場景，存在較小維護視窗 | 可用，需要有維護視窗進行vacuum |
| 并發量較大，資料量較大，大表DML較多，大并發進行全掃的7*24場景且維護視窗短 | 不建議 |
2.講下Oracle與PG的差別？(oracle和PG的顯著差異在什麼方面)
從部署角度：Oracle比較難以做到快速部署，PG隻有幾十M，更容易輕量級自動內建部署，Oracle有rac叢集架構，支援多寫，PG隻有主備方案，不支援多寫。
從架構體系：Oracle有undo，PG是MVCC實作。
表空間管理：oracle可以自動擴充表空間，pg的表空間是檔案目錄，主備環境擴充時備庫一定要先建立目錄，否則會當機。
性能分析：PG原生沒有AWR，有簡單的第三方實作。
從功能角度：Oracle大而全，PG原生功能簡潔，擴充功能豐富，是一個一專多長的全棧資料庫(時序、圖、sharding等）
SQL标準支援角度：PG符合度更高，例如json及json path。
3.PG有沒有像Oracle RMAN那樣的聯機資料熱備？能支援任意時間點的恢複嗎？
PITR基于時間點、事務、還原點都支援，備份工具有pg_rman支援單機操作、pg_probackup支援單機或遠端執行個體，也支援恢複到db級别。
4.PG也支援類似的RAC共享存儲的嗎？
可以借助系統叢集套件，軟體層面支援。
5.POSTGIS的使用場景及如何使用？
與位址坐标位置相關同時想再資料庫層做查詢計算，可比如公交行業車輛軌迹分析，智能監控等，可以參考POSTGIS官網，有參考案例。
6.PG裡的存儲過程強大嗎？跟Oracle裡差别大嗎？
PG原生隻支援函數的概念，新版本也支援存儲過程以及函數裡手動commit/rollback操作，功能跟oracle的存儲過程一樣很強大，而且支援不同的程式設計接口，C、Java、Python、Perl等，package需要通過schema包裝實作。
7.有沒有在PG裡寫函數和存儲過程實作業務邏輯的。
非常多，本人之前從事的公交行業IC卡收費系統大量複雜的業務邏輯如售卡充值挂失等都是基于PG函數實作。
8.Oracle轉PG,存儲過程是不是要改寫 ？
本身PG與Oracle的設計理念相似，plsql跟pgsql文法很類似，但Oracle特定文法需要改寫。
9.入門書籍有推薦的嗎？
《PostgreSQL修煉之道：從小工到專家》
《PostgreSQL伺服器程式設計》
《PostgreSQL實戰》
《深入淺出PostgreSQL》
《PostgreSQL指南内幕探索》
10.PG主要應用在哪些地方？
我接觸從事過的行業有公交、銀行、傳統ERP體系，主要應用于企業自研産品，另外PG曆屆大會及網上可以查
國内各行各業都有實踐應用。
11.講講PG和MySQL的差別呗？
早期版本的PG性能不太好，由于關系模型支援得很好，用起來會有諸多限制，學習成本會比較高，比起這些，MySQL要輕量很多，到現在這也是它的一個優點，在網際網路這個特定的場景中，大家為了追求快速疊代和拓展性，使用的SQL功能不會太多，都夠用，而PG 由于更嚴謹的SQL關系模型，很多用法都限制得比較死，MySQL卻要靈活很多。
12.PG和MySQL,Oracle的差別，各自的優缺點是什麼。
PostgreSQL是一個資料庫程式設計平台，接口開放，類似樂高積木，相關的配套工具不太完善，需要使用者自己內建。
Oracle是成熟完善的商業産品，功能大而全，不夠輕量級。
MySQL本人沒什麼實踐。
13.PG有叢集環境嗎？
原生有內建備份、主備切換接口，WAL日志也開放接口，有基于pgpool做叢集，實作連接配接池、負載均衡及高可用，也有基于keepalived+VIP方案、repmgr方案、patroni方案等主備方案，需要自己內建搭建。
14.PG12試用過嗎？與PG10在使用上有沒有明顯的性能提升？
目前實踐都是基于PG12，與10相比使用pgbench測試性能沒有太大提升，但并行以及分區表性能有提升，12恢複及備庫觸發方式等有調整，配置使用上有一些變化。
15.生産環境，目前建議用PG哪個版本。
求穩建議10，市面上的最新書籍大多基于10，12也已經比較穩定了。
16.快速入門,需要學多久時間
有基礎的，我覺得2天能實踐入門，能幹活，深入的話需要持續學習。
17.有Oracle遷移PG經驗麼？
有做過公交行業的Oracle遷移到PG，現在也在做這方面的工作。
18.從入門到精通要多久？
一般來說入門容易，精通難。
19.為什麼現在很多企業選擇Oracle轉PG呀？
可能有節約成本的因素，自研可控因素，就如IT公司無論大小都有軟體部門。
20.PG資料庫，這個可以用于大型業務系統不。
本人參與實踐落地的公交項目（準金融業務系統），從13年上線運作，15年底切換PG新版本，現在穩定運作，國内很多同行也有介紹不同行業不同的大型業務系統均有實踐。
21.PG目前國内的在使用客戶多麼？
超過100+，包括阿裡、騰訊等。
22.講一下PG優化吧？
一是作業系統級别的參數調優，二是postgresql.conf裡的參數調優，三是應用調優，查詢索引優化等，後面有機會整理分享。
23.PG讀取空間資料，性能如何提高？
PG裡有适合GIS空間類型的索引，能提高查詢性能。
24.PG高可用當中，備庫的WAL檔案什麼時候會被清理？ 遇到過備庫WAL分區被撐滿的情況？
生産環境經常可能出現WAL日志缺失，備庫無法恢複或者堆積造成資料庫磁盤打滿的情況。
WAL檔案的清理和下面幾個因素有關：
-
max_wal_size、min_wal_size參數
min_wal_size指定pg_wal目錄裡的wal段檔案的最小值，這些數量的段檔案總是被回收使用，
即便可能用不到這麼多段也是如此，設定該值有助于防止備庫需要的日志被主庫删掉，但是隻是減緩，并不是根治。
max_wal_size限制了最多的wal段日志的大小，但是該限制并不是硬限制，
如果某段時間由于業務量比較大造成wal日志量超過max_wal_size限制的值，
那麼檢查點程序會啟動，将一些以前的段檔案變為無用進行清理。
-
wal_keep_segments參數
該參數獨立于其他參數設定，pg總是保留最少wal_keep_segments個wal段檔案，
設定該值也對主備流複制環境的wal日志保留有所緩解，但是同樣不能徹底解決。
-
archive程序
如果配置了歸檔，當wal段檔案還未來及被歸檔時，即使滿足了其他清理條件，
wal段檔案也不能被清理。甚至假設我們配置的archive_command錯誤造成歸檔失敗，
那将是災難性的，所有的wal都将無法清理。
-
複制槽的使用
複制槽的使用可能帶來主庫的wal日志不能被清理或者清理速度較慢帶來資料堆積。
我們一般使用實體複制槽來確定流複制環境中備庫需要的wal日志不被主庫清理。
25.感覺目前PG的市場不大，用的人少？
如果仔細了解下，現在PG市場趨勢一直在增長。
26.PG現在主流版本是那些？推薦學什麼版本？
生産系統使用主流版本9和10，推薦10做生産，學習建議學12及新版本
27.pgpool怎麼樣？穩定性如何？
Pgpool-II周圍有不少人使用，穩定性可以，還有連接配接池、負載均衡等功能。
28.PG做資料倉庫怎麼樣？
可以基于fdw方案做。
29.與ORACLE比較，處理資料的吞吐量， 查詢，寫、讀等比較一下性能
Insert和Update差别不大，update操作oracle是直接修改原記錄，PG是MVCC插入新版本，表和索引有膨脹。
查詢方式索引掃描PG效率略低，全表掃描PG受MVCC影響，效率低一些。
文章來源：https://www.modb.pro/db/21903
![Mysql表結構轉Postgresql建表語句快速操作[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)