エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
PostgreSQLが遅いときにcostとactualを確認しよう
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
PostgreSQLが遅いときにcostとactualを確認しよう
OracleからPostgreSQLに移行する際に起きた問題。 PostgreSQLをインストールし、テーブルを作成してデー... OracleからPostgreSQLに移行する際に起きた問題。 PostgreSQLをインストールし、テーブルを作成してデータをインポートした。 が、検索が妙に遅い。 実行計画を見ると、インデックスを参照していない。 よくよく見てみたら、OracleにはあったインデックスをPostgreSQLには作成していなかった。 そりゃ参照しねえわと思い、インデックス張ってみた。 でも遅い…。確かに何個ものテーブルをJOINして、何十万行もの結果を返すとはいえ、30分はかかりすぎだろう。実用にはとても耐えられない。 explain analyzeで実行計画を見ると、costで予測する行数とactualで実際に取ってきた行数が異常に乖離している。これはおかしい。いくらなんでもおかしすぎる。costでは数千万、数億行取得すると予測しているのに、実際には数十万行程度しか取得していなかった。 もしかして、実行