Does indexing help >= as well as = for integer columns?
От | TJ O'Donnell |
---|---|
Тема | Does indexing help >= as well as = for integer columns? |
Дата | |
Msg-id | 2842.209.223.166.104.1107284205.squirrel@gnova.com обсуждение исходный текст |
Ответ на | Re: visualizing B-tree index coverage (PFC <lists@boutiquenumerique.com>) |
Ответы |
Re: Does indexing help >= as well as = for integer columns?
Re: Does indexing help >= as well as = for integer columns? |
Список | pgsql-general |
I have a table of about 5 million rows, 24 columns. Integer column _c is BTREE indexed (as is _n, _o and 3 others). This I understand and like: Explain Analyze Select count(smiles) from structure where _c = 30 Aggregate (cost=105595.11..105595.11 rows=1 width=32) (actual time=17.722..17.724 rows=1 loops=1) -> Index Scan using "Nc" on structure (cost=0.00..105528.89 rows=26486 width=32) (actual time=0.098..16.095 rows=734 loops=1) Index Cond: (_c = 30) Total runtime: 18.019 ms This I don't get. Why is an index scan not used? Isn't an index supposed to help when using > < >= <= too? Explain Analyze Select count(smiles) from structure where _c >= 30 Aggregate (cost=196033.74..196033.74 rows=1 width=32) (actual time=42133.432..42133.434 rows=1 loops=1) -> Seq Scan on structure (cost=0.00..191619.56 rows=1765669 width=32) (actual time=8050.437..42117.062 rows=1569 loops=1) Filter: (_c >= 30) Total runtime: 42133.746 ms TJ
В списке pgsql-general по дате отправления: