Showplan Operator of the Week - Lazy Spool - Simple Talk
Continuing to illuminate the depths of SQL Server's Query Optimizer, Fabiano shines a light on the sixth major Showplan Operator on his list: the Lazy Spool. What does the Lazy Spool do that's so special, how does the Query Optimizer use it, and why is it so Lazy? Fabiano explains all... Lazy Spool Just in case if you haven’t been following my articles, I’m writing a series about the SQL Server Sh
データベースコンサルタントのノウハウちょい見せ RDBMSの推移律
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります 今回は、RDBMSの推移律についての説明です。これは集合演算を背景として持つため、リレーショナルDBMS特有と言ってよいと思います。もちろん、難しい話は抜きですので、ご安心ください。 表testAと表testBがあるとします。表testAにも表testBにも「no」という番号の列があるとして、 where句にtestA.no = testB.noという結合条件もあるとします。その場合、testB.empno=10という条件は、testA.empno=10とも解釈できますよね？ これが推移律の例です。本当は集合論的に「この集合とこの集合がこう
PostgreSQLを遅くしている犯人はどこだ？
出力内容を追いかけろ 実際に実行してみてどれだけの時間がかかったかは「actual time=」で表示される数値を追いかけることで確認可能です。例えば、前ページのリストの1行目に出力されている「actual time」だけを取り出すと、次のようになります。 ↓最初の1件目を取得するまでにかかった時間 (actual time=9006.586..9011.968 rows=16842 loops=1) ↑最終的に結果行全体を取得するのにかかった時間 特に、右側の数値である「最終的に結果行全体を取得するのにかかった時間」では、そのSQLの処理開始からの累積時間で表示されます。このため、当該行の処理が完了するまでにどれだけの時間がかかったかを確認できます。 これを基に、SQLの中でどの処理に最も時間がかかっていたのかを確認していきましょう。 Total runtimeが9022.840msであ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Operator of the Week - Index Spool - Simple Talk
