とあるクエリを2万倍速にした話 -データベースの気持ちになる- 後編 - dwango on GitHub
技術コミュニケーション室 OSSグループの髙﨑です。 本記事は、とあるクエリを2万倍速にした話 -データベースの気持ちになる- 前編の続きです。 前回の記事でお話しした内容がPullRequestを作ったときの過程だったわけですが、 そのような結果に至った経緯、Index Only Scanを使わなかったPostgreSQL特有の事情について、 PostgreSQLのアーキテクチャなども交えもう少し詳しくお話させていただきます。 要するに 実行計画のコストとはレコードやindexの読み込み、フィルタ処理などからその実行にどの程度の時間が必要となるかの推定値 indexを張る際にはそのindexがどのように辿られるかを意識する必要がある 範囲検索される可能性があるカラムはindexの先頭にはあまり適さない PostgreSQLにおけるIndex Only Scanは新しい/更新頻度の高いデー
とあるクエリを2万倍速にした話 -データベースの気持ちになる- 前編 - dwango on GitHub
技術コミュニケーション室 OSSグループの髙﨑です。 当グループでは、マストドンというオープンソースの分散型マイクロブログについて、 弊社が運営するインスタンス「friends.nico」の運営、独自機能の開発、運用、ならびにそれらで得た知見を上流のプレーンなマストドンへcontributeするという業務を主に行っています。 本記事では、tableに適切なindexを張ることによってとあるスロークエリの速度改善を行った事例について、実際に上流へ行ったPullRequestをベースにお話させていただきます。 内容としては反面教師とするべき失敗例を伴った、非常に基礎的なPostgreSQLの実行計画の読み方ならびにクエリに合わせたindexの張り方です。 また、表題の2万倍速というのは改善前の最悪の場合比であり嘘ではないものの、通常問い合わせされる範囲の条件ではだいたい3〜30倍速であるという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
