Tom Lane <tgl@sss.pgh.pa.us> writes:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>
> > Yes, if it is selective enough. (It _can_ use the index, which does not
> > mean that it _will_ use it.) Note that if your example query used the
> > columns (lname, dob), the answer would be "no."
>
> Actually, that last point is not true anymore as of 8.1 --- see this
> thread:
> http://archives.postgresql.org/pgsql-hackers/2005-05/msg00939.php
> which led to this patch:
> http://archives.postgresql.org/pgsql-committers/2005-06/msg00156.php
Did that patch actually implement "skip scanning"?
The comment seems to only describe removing the restriction from the planner.
Which would make it theoretically possible but presumably the the cost
estimator should ensure it essentially never gets chosen for btree indexes.
The btree index would very very rarely help since it would require a complete
index scan.
I guess I could see some corner cases where it would help. Very wide tables
with an index on a few very selective relatively narrow columns. So the index
could be scanned in its entirety much faster than a full table scan. But the
index would have to be *much* narrower than the table and quite selective
to overcome the random access penalty.
Skip scanning would make it much more likely to be helpful.
Also, I think Oracle has another scan method called a "fast index scan" that
basically does a full sequential scan of the index. So the tuples come out
unordered but the access pattern is sequential. Would that be a good TODO for
Postgres? Is it feasible given the index disk structures in Postgres?
--
greg
