データがない場合、使用制限は非常に遅い

Question

SQLは非常に簡単です。 "orders_express_idx" btree（express）。 expressはインデックスです。

がうまく機能します。 express aが存在するためです。

select * from orders where express = 'a' order by id desc limit 1; 

Limit (cost=0.43..1.29 rows=1 width=119) 
-> Index Scan Backward using orders_pkey on orders (cost=0.43..4085057.23 rows=4793692 width=119) 
    Filter: ((express)::text = 'a'::text) 

が遅くなります。データは存在しません。私は限界を使う。

select * from orders where express = 'b' order by id desc limit 1; 

Limit (cost=0.43..648.86 rows=1 width=119) 
-> Index Scan Backward using orders_pkey on orders (cost=0.43..4085061.83 rows=6300 width=119) 
    Filter: ((express)::text = 'a'::text) 

がうまくいきます。データは存在しません。私は限界を使用していませんでした。

select * from orders where express = 'b' order by id desc; 

Sort (cost=24230.91..24246.66 rows=6300 width=119) 
Sort Key: id 
-> Index Scan using orders_express_idx on orders (cost=0.56..23833.35 rows=6300 width=119) 
    Index Cond: ((express)::text = 'a'::text) 

Answer 1

https://www.postgresql.org/docs/9.6/static/using-explain.html

ここ

でseciotnに行くLIMITの効果を示す一例である：

、さらに：

これがされサム上記のようにeクエリを追加しましたが、LIMITを追加して、 の行を取得する必要はなく、プランナーは約 の作業を変更しました。インデックススキャン ノードの総コストと行数は、完了まで実行されたかのように表示されます。ただし、Limit ノードは、これらの行の5分の1だけを取得した後に停止することが予想されます（ ）ので、合計コストはわずか5分の1になります。実際のクエリの推定コストは です。この計画は、 リミットノードを前の計画に追加することよりも優先されます。リミットはビットマップスキャンの開始コストを支払う を避けることができないため、合計コストは です。

だから基本的にはそうです。 LIMITを追加すると計画が変更され、小規模なデータセット（期待）に効果的になりますが、影響は負になります（スキャンコスト、effective_cache_sizeなど）。

Ifしかし、基本的にこれは文書化された動作です - LIMITはプランと実行時間を変更します - はい