sakamoto
sakam****@ma*****
2007年 12月 13日 (木) 18:49:44 JST
こんにちは、坂本です。 幸坂さん、加納さん、折角お返事いただいたのに、 返信出来ずに申し訳ありませんでした。 お返事兼ねて、現在の状況をお知らせします。 幸坂さんのご指摘にあった １．*.SEN.i.c以外をキャッシュに乗せ ２．SELECT COUNT(*) FROM tab;を実施 を実施することで高速にアクセスできるようになったため、 これを実施することにしました。 キャッシュに乗せきれない場合は、効果薄いかも知れませんが、 改善できるケースがあるということで。 また、これを一定期間後にも自動で実施することで、 途中で、フラッシュされた場合にも備えることにしました。 加納さんのご指摘の、インデックスとデータの関係は、 目からうろこでした。 通常は、全件（今回は２０万件）ヒットさせるようなことは無いと 思いますが、データの内容や検索の方法によっては、こういう ケースも許しているのが現状です。 最初にヒット件数のみ取得して、閾値以上の場合は、 警告メッセージを出して再検索させるということもやっていますが、 現状ではLudia のpgs2getnhits関数は、直前の検索を実行していないと ならないとか、更新が入ると正確な件数にならないとか、そのほか、 弊社PPの仕様的な面も大きく利用できないでいます。 ＃本件は一応解決したことにしておりますが、別件で、また 期待の動作をしない部分があり、それについては、別途ご連絡させて いただきます。 > こんばんは、加納です。 > > 幸坂からの回答とは別に・・・ > > > > 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アクセスが必須 > だとしたら、かなりつらい要件です。 > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users
