Tom Lane wrote:
>The fundamental problem is that you can't do it without adding at least
>16 bytes, probably 20, to the size of an index tuple header. That would
>double the physical size of an index on a simple column (eg an integer
>or timestamp). The extra I/O costs and extra maintenance costs are
>unattractive to say the least. And it takes away some of the
>justification for the whole thing, which is that reading an index is
>much cheaper than reading the main table. That's only true if the index
>is much smaller than the main table ...
>
> regards, tom lane
>
>
I recognize the added cost of implementing index only scans. As storage
is relatively cheap these days, everyone I know is more concerned about
faster access to data. Similarly, it would still be faster to scan the
indexes than to perform a sequential scan over the entire relation for
this case. I also acknowledge that it would be a negative impact to
indexes where this type of acces isn't required, as you suggested and
which is more than likely not the case. I just wonder what more people
would be happier with and whether the added 16-20 bytes would be
extremely noticable considering most 1-3 year old hardware.