私はdaterangeの列を持つテーブルを持っています。今日の日付を含む行を選択したいと思います。範囲の種類の範囲contains elementPostgresqlで範囲の型を指定する
インデックスがGiST index
で作られている場合
select * from mytable where drange @> now()::date
@>オペレータはので、私はCREATE INDEX my_idx ON mytable USING gist (drange)
しかしexplain select * from mytable where drange @> now()::dateは常に
Seq Scan on mytable (cost=0.00..1051.82 rows=26104 width=38)
Filter: (drange @> (now())::date)
インデックスが良好です。おそらくPostgreSQLがインデックスを選択するのに十分条件が選択的ではないでしょう。
パラメータrandom_page_costを低く設定すると、PostgreSQLがインデックススキャンのためにもっと決定できるようになります。
私はあなたがそれはPostgreSQLがを選択するために今して低い値（1、1.5または2）へrandom_page_costセットされた数であるように、テストのカップルは、シーケンシャルのschanでEXPLAIN (ANALYZE)で実行実行することをお勧めしたいですインデックススキャンまたはビットマップインデックススキャン。その後、どのオプションが最も速いのかがわかります–逐次スキャンの可能性があります。
クエリを複数回実行するとデータブロックがキャッシュされるため、非現実的に良い結果が得られることに注意してください。あなたは“コールド”キャッシュ上のパフォーマンスを比較するべきです。これは、PostgreSQLサーバを再起動して（および/またはオペレーティングシステムのファイルシステムキャッシュを空にして）シミュレートすることができます。