Re: Does indexing help >= as well as = for integer columns?

> 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.