pg_stats_reporter読影会をやってみた

2016-09-10 第8回PostgreSQLアンカンファレンス

自己紹介

『SQLアンチパターン』社内読書会には喜んで遊びに行きますので、お気軽にお声がけください。これまで何社もお邪魔しましたが、社内でないとできない実システムを肴にしたアンチパターンの話が盛り上がります。
— Takuto Wada (@t_wada) 2016年5月20日

きょうはスクショで。一部伏せ字、関係ないところは数値を捏造しているのでご安心を。

応答時間　5sec 〜　17sec もかかるAPIが散発

残念ながらpg_stats_reporterは持ち出せない

"Heavily Updated Tables" に database:postgres, schema:statsrepo のtableが上位に複数出てくる。pg_stats_report はそれなりの記録負荷がかかるもの。記録を欲張ると性能破綻するという本末転倒がありうる。
"Heavily Accessed Tables" で一番注目しているのは"seq_tup_read":シーケンシャルスキャンによって読みとられた行数
tup_per_seq が大きくてもアドホックなSQLによる単発なら性能問題にはならない。セキュリティ案件にはなるかも。

Heavily Accessed Tables
Top 2 が user_info と member の TABLE
メンテ・分析専用カラムだったはずの update_at をビジネスロジックがSQLに取り込んでしまった。INDEX追加するよりは、ロジック修正する方向。
"Statetemts"の call の回数と seq_scan 回数がほぼ一致しているので、要修正のSQLはこの2つ