Hatena::Grouppostgresql

PostgreSQL 雑記 このページをアンテナに追加 RSSフィード

2009-05-07コスト推定@textsearch_senna このエントリーを含むブックマーク このエントリーのブックマークコメント

textsearch_senna で、実行計画のコスト推定処理をサボっていたのが バレてしまった ので、sen_records_nhit を使って実装してみました。無くても動くことは動くタイプのものなので、実際に使う人が見つかってからでも良いかと思っていた箇所です。ちなみに、実装が必要なのは am_costestimate 関数ではなく、CREATE OPERATOR (RESTRICT) で渡す関数になります。

多少小細工してみたのは、コスト推定のコストを抑えることです。コスト推定処理は planner から呼ばれますが、実際のデータ取得は executor から呼ばれます。planner と executor で検索処理が 2回呼ばれるのが気になったので、結果を一時的にキャッシュし、executor で検索結果を再利用するようにしてみました。

あとは、その他のツッコミに対してですが:

  • インデックスファイルが消えない

現状のアクセス・メソッドの仕組みでは、DROP イベントが無いんですよね。VACUUM も「存在するテーブルやインデックスに対する処理」ですから、既に DROP 済みのインデックスに対しては呼ばれません。また、"CREATE TRIGGER ON DROP" もサポートされていないので、論理イベントから攻めることもできません。

PostgreSQL 本体を改造して DROP イベントを追加するか、逆に Senna を改造してインデックスを 1ファイルにまとめることができれば良いのですが (現在は 4ファイル使います)。

  • EUC-JPDBでテストが通らない

リグレッションテストのフレームワーク (pg_regress) のマルチバイト対応に問題があるのかもしれません。手が空いたら試してみましょうか。