Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
0
Help us understand the problem. What is going on with this article?
@nishimura

PostgreSQLの Planning Time のチューニング

More than 1 year has passed since last update.

長大なSQLを書いていると

explain analyze
-- ... 100行以上の SQL

-- ... 100行以上の実行プラン


 Planning Time: 17.411 ms
 Execution Time: 1.675 ms

という感じになって、Execution Time より Plannning Time を高速化する必要が出てきた。
PostgreSQLは実行プランをキャッシュできないらしい。
https://use-the-index-luke.com/ja/sql/explain-plan/postgres/concrete-planning

この重いSQLだけ実行するコネクションプーリング用サーバーを置けばプリペアドステートメントでキャッシュできそうだけど、それはちょっとやりすぎである。

素直にPlanning Timeを高速化することを試す。

と言っても検索しても特に情報もなく、あれこれ試行錯誤して

explain analyze

-- ...

 Planning Time: 8.543 ms
 Execution Time: 1.680 ms

倍の早さになった。
ちょっとしたサンプルコードは無し。そもそもPlanning Timeが1msを超えるようなSQLはめっちゃ長いので簡単なサンプルというのは作れなさそう。

何をしたかというと、joinの条件をシンプルにした。
usingで重複を消すために列を追加したり、条件は無いよりはあった方がいいよね的にjoinの結合条件を複数指定していたんだけど、プライマリキーやユニークキーから複数の結合条件を選択できるようなjoinはやらない方が良いっぽい。
例えばアカウントIDとemailが共にユニークで、ログインテーブルとアカウントテーブルの結合はどちらでも出来る場合、無いよりはプランナに選択を任せよう的にjoin条件に二つとも指定するとPlanning Timeが遅くなるようだ。(いや、これぐらいの小さい選択ならどちらでも変わらないかもしれない)

27個のテーブルを結合してNested Loop が13階層ほどになってるが、Execution Timeは速い。
rows=1 loops=1 の結合が多いからだろうけど。

0
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
0
Help us understand the problem. What is going on with this article?