f
Postgres sequence currval 效能問題及GCP Query Insight工具 ~ 迪貝之家
skip to main |
skip to sidebar
最近在寫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 就是好用 |