象と戯れ

 | 

2009-05-05

textsearch_sennaのコスト推定

23:22 | textsearch_sennaのコスト推定 - 象と戯れ を含むブックマーク はてなブックマーク - textsearch_sennaのコスト推定 - 象と戯れ

textsearch_sennaを試しています。やっぱDB的検索(=NOTドキュメント検索)には、LIKE互換な文字列マッチングが必要なのです。

でいろいろ試していて気になった点をいくつか。

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

Ludiaのときからこれが気になってしょうがない。ドキュメントによれば「DROP INDEXしないで専用の関数を呼んでください」ということなのですが、やはり気になる。インデックスアクセスメソッドに詳しくないので勝手な物言いですが、VACUUMのときとかに不要なインデックスファイルって消せないものなんでしょうか??

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

テストはUTF8で書かれているので、EUC-JPでinitdbしたDBに対してmake checkinstallすると日本語部分が表示されておらず、テストが通らないです。手動でPgAdminとか使えば挙動は確認できるので大きな問題ではないですが。

・コスト推定がうまく働かない

Ludiaは独自にコストを計算していたのですが、 [Ludia-users 83] インデックスコスト推定関数について のような結果に陥っていて「どうしてこうなるの」と思っていました。textsearch_sennaのソースを見ると、

Datum
senna_costestimate(PG_FUNCTION_ARGS)
{
	/*
	 * We cannot use genericcostestimate because it is a static funciton.
	 * Use gincostestimate instead, which just calls genericcostestimate.
	 */
	return gincostestimate(fcinfo);
}

となっていて、src/backend/utils/adt/selfuncs.cの標準装備コスト推定関数の結果を利用しています。が、これはこれで問題のようで、手元の環境でいくつか試した結果、推定結果行数がいつも同じ→適切なJOIN戦略が選ばれない→全体としてパフォーマンスが(それほど)よくならない、という事態になっています。絞り込み自体が速くなるので通常のLIKEに比べれば速いのですが、、、結果5件と元の10万件テーブルとのJOIN(JOIN KEYはbtreeインデックス済み)で、推定結果が常に1万件近くなので実際のヒットが5件でも1万件でも常に10万件のテーブルのSeqScan→HashJoinとかしてて、5件ヒットのときはIndexScan→NestLoopとかしてくれ、と思うわけです。

senna_records_nhitをコスト推定関数の中で呼び出して予め件数をとってしまう、というのはできないのでしょうか、と思った次第です。おまえもプログラマの端くれならコード書いて示せ、といわれそうなので時間ができたらもうちょっと真面目に見ようと思っていますが、、、PGConの資料も出来てないし、しばらくはムリそうです。。。

ただ、全体的にはLudiaに比べて堅牢に作ってあるような気がするので、安心して使っています。8.4限定で書いているというの(これはLudiaのせいではない、インデックス周りの変更が激しすぎるだけ)と、何よりPostgreSQLの中に詳しい人が書いているというのはそれだけで心強いですね。

こういうことはMLに投げるべきかもしれませんが、取り急ぎ。

 |