Postgresは簡単なORDER BY LIMIT 1でインデックスを使用しないのはなぜですか？

Question

私は大きなテーブル（約11,000,000行）を持っており、ソート条件が与えられた最初のアイテムを見つける必要があります。この単純なクエリに

CREATE INDEX track_ix_date 
    ON "Track" 
    USING btree 
    ("Date" DESC NULLS LAST); 

：

select * from "Track" order by "Date" desc limit 1 

しかし、それは使用しない列DateがはなぜPostgresはインデックスを使用していないヌル

をを受け付けない

注意この他のクエリ：

select * from "Track" order by "Date" desc nulls last limit 1 

2番目のクエリは、最初のクエリよりもはるかに高速です。

私はindexes and ORDER BYマニュアルを読み、ソートがちょうどに、フルテーブルをスキャンする必要がありますのでLIMIT句とORDER BYの特殊な場合には、はるかに効率的なインデックスの代わりに、テーブルをスキャンを使用することがあると言っているしています単一の項目を得る

Postgresは、nulls last/firstは、カラムがヌルを受け入れず、もっとも速いメソッドを使用するので、問題ではないことを検出するべきですか？

Answer 1

オプティマイザをスマートにすることは、オプティマイザの速度を遅くすることも意味します。これは、誰もが傷ついてしまうからです。

現在のところ、スマートではないため、インデックス定義またはクエリを変更して機能させる必要があります。

pgsql-hackersメーリングリストでこのような改善を求めたり、自分でパッチを作成してそこに投稿したりする価値があります。