>
> It's a fairly corner case feature, only for the case where you're
> looking for the existance of an index key but don't want any other
> data. I don't personally have any queries that could use such a
> construct, though maybe I'm missing the point.
I understand the difficulty of implementation of such a new feature and
the advantages and disadvantages coming with it.
But let me give you one of the most important usage of index only scan:
if one has two relations A(a1, a2, ..., an) and B(b1, b2, ..., bn) and let
b1 be a foreign key of one of the ai of A, (e.g of aj).
And let q be a query like:
select A.ai
from A, B
where aj = b1
which is one of most common join queries,
then there if one has an index on b1 on relation B, there is no reason to
scann the whole table B, but only the b1 attribute. A good optimizer would
select index only access path, because it's the most selective acess path.
Eg. index nested loop algorithm for join, taking relation A as outer, and
B as inner, has to scan the whole relation B (Vs the whole index on B) for
each tuple(or block) of outer rel A.
Also, there are other less frequent examples in which index only acess
path is the optimal one.