しくみ分科会+アプリケーション分科会勉強会
2011/10/29(土)に開催された勉強会に行ってきたので、聴講中のメモを備忘録として書いておきます。
Explaining EXPLAIN 第3回
前々回、前回からの連載記事。SQL チューニングについての Tips 的な話。Oracle ではチューニングを色々やったけど、やはりコストベースのプランナーは 80点くらいのプランしか出せない、という前提なのだろうか。懇親会でも話題に出てたけど「速くならなくていいから遅くならないで欲しい」という要望にどう応えたらいいのか…。
- SSD を使う場合はデフォルトのコスト値 index_scan_costs = 4.0 (seq_scan_costs の4倍)は大きすぎるかも。
- 結合条件の列名が同じ場合は USING (列名) でいける。外部テーブルの JOIN push-down でもサポートしているか不安になった。
- バージョン 7.4 までは、ANALYZE していないテーブルの見積もり件数は 1000 件になる。これを聞いた翌日、「pgsql_fdw が大量のメモリを消費してバックエンドが落ちる場合がある」という指摘を受けた。
- VACUUM 後でも、削除されたタプルを含めてスキャンするとのこと。インデックススキャンの話だったかな？9.2 からは index only scans が採用されたので、少し事情が変わりそう。
- 聴講者から「VACUUM FULL でディスクフルになった場合の挙動は？」という質問が出ました。板垣氏によると「VACUUM FULL に限らずデータファイルに関するディスクフルならば個別処理のエラー終了のみでクラッシュやデータ損失はない。ただし、WAL はディスクフルに弱いのでパフォーマンス以外の観点でもパーティションを分割しておいたほうが良い」とのこと。
- 「EXPLAIN 結果を可視化するツール/サービスはないか」という質問がでた。勉強会後にも調べたがコストまで含めて分かりやすい表示のものは意外とないようだ。
- pgAdmin3:実行計画をグラフィカルに表示してくれる。細かいところだけど、上位ノードに返されるデータ量が矢印の太さに反映されているっぽい。
- explain.depesz.com:実行計画を収集しているサイト。history ページでは実行計画のノードごとの情報を色分けして表示してくれる。
- Visual Explain:pgAdmin3と似たような表示。
データベースの古くて新しいボトルネック：ロック(WAL）
久しぶりに「しくみ分科会」という感じのネタでした。かなり駆け足だったので、若干消化不良かも。
データベース組み込みの全文検索を使うには(後編)
前回に続いて、全文検索。社内システムで使ってみようかと思ったけど、LIKE も以外と速いと聞いたので再考中。
- N-gram の説明の「N文字のデータをインデックシングするのではなく、1文字のデータに最大(N-1)までの付加情報をつけてインデックシングする」と聞いてなんとなく納得。
- pg_trgm を日本語で使うにはリビルドが必要とのこと。ドキュメントに書かないときっとみんなはまる。ソースコードからのビルドを許さないサイトでは採用できないということか。
- Prepared Statement でもインデックスを使ってくれる。
- 文中に改行やスペースがあると説が切れるのでデータ投入前にクレンジングすべし。
- pg_trgm は 8.3や8.4でも動くかも。textsearch_sennaは8.2以降で動く。
- 質疑応答では、サジェストや暗号化したテキストの検索、ランキング処理などアプリケーション側の仕様と関連した質問が多かった感じ。どこまで DB でやってどこからアプリケーションでやったらよいのか、中々きれいな答えは出ないみたい。
懇親会
色々な方と話せて毎回楽しいです。こっちがメインといってもよい？後で聞いたら二次会もあったらしい。惜しいことをした…。
