Toshihiro Kano
kanou****@nttda*****
2007年 10月 15日 (月) 17:57:30 JST
こんばんは、加納です。 幸坂からの回答とは別に・・・ > > SELECT COUNT(*) FROM tab; > →（SQL1)とします > > > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; > →（SQL2)とします > > [ケース１] マシン起動→SQL1→SQL2 > SQL1,SQL2共に遅い。 > > [ケース２] マシン起動→SQL2→SQL1 > SQL2は遅いが、SQL1は速い > > SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > いうことでしょうか。 SQL1のパターンも、PostgreSQLのテーブル部を参照します。 もし、COUNT(*)はインデックススキャンだという認識でのお 話であれば、それはPostgreSQLには当てはまりません。 PostgreSQLはインデックスも追記型のため、データ部を参照 しないと確実にその行が生きていることを保証できないため です。（インデックスに無効フラグはあるが、無効フラグが オフだからといって、有効とは限らない） SQL1では、プランを確認しないとなんともいえませんが、 テーブルスキャンの可能性があります。その場合、シーケン シャルアクセスです。 SQL2では、インデックス経由のアクセスですので、テーブル はランダムアクセスです。SQL1<SQL2なのは、予想される結果 です。ケース2のSQL1だけ早いことの解釈にはなっていません が。そのあたりはメモリとの兼ね合いのように思います。 根本的には、ヒット件数を削減していただくことしか対処はな いように思います。20万件全件ヒットのLudiaアクセスが必須 だとしたら、かなりつらい要件です。
