データベースの分離レベルをめぐる冒険(I.イントロダクションとII.MySQLの場合) | キムラデービーブログ
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト（ブログ、またはウェブサイト）において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 とある原稿を書いていて、トランザクションまわりをチト調べている私です。 あまり深みに入らなければ、4つのトランザクション分離レベルと、それぞれのアノーマリを説明して、はい、終わり、ということにしたいのですが、私には以前気づいてしまった以下の記事があり「あれ、四つ多くない?」を細かく調べることなく放置していたのでした。 Web開発者が知っておくべき八つの分離レベル しかし、ここで調べなければもやもやは晴れないですし、 神林さんがシリアライズでもパフォーマンスに問題のないRDBMSの実装が終わり、
PostgreSQLの Planning Time のチューニング - Qiita
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を高速化することを試す。 と言っても検索しても特に情報もなく、あれこれ試行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
