Postgres sequence currval 效能問題及GCP Query Insight工具

 

最近在寫go 程式
把資料轉進GCP Cloud SQL Postgres 13
碰到sequence 物件叫用currval的效能問題
邏輯大概是這樣
塞到主表資料後
再用currval抓出主表該筆資料的json資料展開後
再塞到子表
可是主表已經把identity欄位設為主鍵
基本上應該不會有效能問題
結果170幾萬筆的資料
程式跑了一天半跑不完
而且從table size 的數字看起來
資料匯入連一半都不到
碰到這種狀況
只好改寫程式
在insert主表時,return identity欄位的數值
再用strconv package把數值轉為文字
大概3個半小時就能跑完所有的資料
此時當然就在想,為什麼呢?
以前管地端的postgres
auto_explain及pg_stat_statements
這兩個extension我一定會用
一個是看執行計畫
一個是sql的執行數據
可是現在用的是cloud managed service
難不成還用地端的思維來管理資料庫及調校程式效能??
其實GCP給了很好的工具...叫做query insight
我不得不說.....真的非常好用
首先我們來看執行計畫的部分

左下我用黃色圈起來的部分
就是currval的運作
掃表以及執行時間是195.56ms
我們再來看改寫後的計畫差異

index scan以及執行時間小於1 ms
上述是auto_explain的功能
那pg_stat_statements呢?
有啦~~query insight也有
這工具整合了不少好東西

我要特別強調
這是程式剛丟下跑的時候
currval 運作的時間
隨著逐筆塞入後
insert select 的速度只會越來越慢
我們再來看改寫程式後的數據

平均執行時間0.03 ms
其實實務上debug的順序
應該是先找到slow query
然後再來找執行計畫
只是因為程式是我寫的
我大概知道問題出在哪裡
就直接去point執行計畫的部分
總之~~ query insigth 就是好用

Posted in: Cloud SQL,GCP,Postgres,Query Insight