Re: About b-tree usage

Ioannis Theoharis <theohari@ics.forth.gr> writes:
> select att0 from tc2000000000 where att1=900000000 AND att1>=0

> plan:
>  Index Scan using inst_id_idx on tc2000000000  (cost=0.00..161603.06
> rows=1000006 width=1004) (actual time=41.21..101917.36 rows=1000000 loops=1)
>    Index Cond: ((att1 <= 900000000) AND (att1 >= 0))
>  Total runtime: 103135.03 msec

> query:
> select att0 from tc2000000000

> plan:
>  Seq Scan on tc2000000000  (cost=100000000.00..100152858.06 rows=1000006
> width=1004) (actual time=0.21..42584.87 rows=1000000 loops=1)
>  Total runtime: 43770.73 msec

> Can you explain me this big difference? Perhaps postgresql caches in
> memory a big part (or the whole) of index?

seqscan is naturally faster when you have to visit the whole table anyway.

> And by the way why postgresql doesn't select sequential scan?

Because you've set enable_seqscan = off.
        regards, tom lane