0
対シーケンシャルスキャンを行うことを好む、なぜ私はそれが行の300万のように含まれている次の表は、主キーの選択：Postgresはインデックススキャン
create table log
(
id bigint default nextval('log_id_seq'::regclass) not null
constraint log_pkey
primary key,
level integer,
category varchar(255),
log_time timestamp,
prefix text,
message text
);
を持っています。
私は次のクエリを比較しています：
次計画得EXPLAIN SELECT id
FROM log
WHERE log_time < now() - INTERVAL '3 month'
LIMIT 100000
：ID命令でORDERで
Limit (cost=0.00..19498.87 rows=100000 width=8)
-> Seq Scan on log (cost=0.00..422740.48 rows=2168025 width=8)
Filter: (log_time < (now() - '3 mons'::interval))
と同じクエリを追加：
EXPLAIN SELECT id
FROM log
WHERE log_time < now() - INTERVAL '3 month'
ORDER BY id ASC
LIMIT 100000
結果は
Limit (cost=0.43..25694.15 rows=100000 width=8)
-> Index Scan using log_pkey on log (cost=0.43..557048.28 rows=2168031 width=8)
Filter: (log_time < (now() - '3 mons'::interval))
私は、次の質問があります。
を指示BY ORDERの不在は、Postgresが行の順序を気にしないようにできます。彼らはソートされていてもよいでしょう。 ORDER BYのないインデックスを使用しない理由
- Postgresは、このようなクエリで最初にインデックスを使用する方法はありますか？
WHEREクエリの句にインデックスのない列が含まれていて、その列をフェッチする場合は、シーケンシャルデータベーススキャンが必要ですが、ORDER BYのクエリではそのことが示されません。
- Postgresは、このようなクエリで最初にインデックスを使用する方法はありますか？
Postgresのマニュアルページは言う：テーブルの大部分をスキャンする必要があり、クエリのために
それはI少ないディスクを必要とするため、明示的なソートは、インデックスを使用するよりも速くなる可能性があります/ Oによるシーケンシャルアクセスパターン
あなたは私のためにこの文を明確にしてくださいすることができ、次の？インデックスは常に注文されます。また、順序付けられた構造体を読み取ることは常に高速です。順序付けられていないデータを読み取り、それを手動で順序付けするよりも、常に（少なくともページスキャンの点で）順次アクセスになります。