Re: Does indexing help >= as well as = for integer columns?
От | PFC |
---|---|
Тема | Re: Does indexing help >= as well as = for integer columns? |
Дата | |
Msg-id | opsli9lrmeth1vuj@musicbox обсуждение исходный текст |
Ответ на | Does indexing help >= as well as = for integer columns? ("TJ O'Donnell" <tjo@acm.org>) |
Список | pgsql-general |
> This I don't get. Why is an index scan not used? Isn't an index > supposed > to help when using > < >= <= too? It should ! > 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 See these : -> Index Scan using "Nc" on structure (cost=0.00..105528.89 rows=26486 width=32) (actualtime=0.098..16.095 rows=734 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) In the index scan case, Planner thinks it'll get "rows=26486" but in reality only gets 734 rows. In the seq scan case, Planner thinks it'll get "rows=1765669" but in reality only gets 1569 rows. The two are way off-mark. 26486 still makes it choose an index scan because it's a small fraction of the table, but 1765669 is not. Analyze, use more precise statistics (alter table set statistics), whatever... but you gotta get the planner correctly estimating these rowcounts.
В списке pgsql-general по дате отправления: