> same here (dual PIII-866, Debian, 512 MB, raid1+0)
>
> real 0m6.472s
> user 0m0.000s
> sys 0m0.010s
>
> real 0m6.195s
> user 0m0.010s
> sys 0m0.000s
>
> real 0m2.885s
> user 0m0.010s
> sys 0m0.000s
This is interesting, just yesterday I was perusing some of Bruce
Momjian's works on PG tuning, and noticed that Postgres prefers sequential
scans over indexes when much of the table has to be read, all because of
the number of head movements on the disk. It would seem that these days,
where RAM is cheap, that most people have a great enough disk cache that
head movements can become irrelevant.
However, I can also see where some people may have incredibly large
tables that just won't fit into RAM. An easy solution to both might be to
create a user-specifiable switch passed at startup that would simply tell
PG that sequentials aren't necessarily better than index scans. Not
completely disabling them, but at least giving it a pointer that it
doesn't *have* to use sequentials.
steve
