Ioannis Theoharis <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
