Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> In the second place, this seems to
>> forever kill the idea of indexscans that don't visit the heap --- not
>> that we have any near-term prospect of doing that, but I know a lot of
>> people remain interested in the idea.
> I'm certainly interested in that. It's not really needed for clustered
> indexes, though. A well-clustered index is roughly one level shallower,
> and the heap effectively is the leaf-level, therefore the amount of I/O
> you need to fetch the index tuple + heap tuple, is roughly the same that
> as fetching just the index tuple from a normal b-tree index.
That argument ignores the fact that the heap entries are likely to be
much wider than the index entries, due to having other columns in them.
> I think we could still come up with some safe condiitions when we could
> enable it by default, though.
At this point I'm feeling unconvinced that we want it at all. It's
sounding like a large increase in complexity (both implementation-wise
and in terms of API ugliness) for a fairly narrow use-case --- just how
much territory is going to be left for this between HOT and bitmap indexes?
I particularly dislike the idea of having the index AM reaching directly
into the heap --- we should be trying to get rid of that, not add more
cases.
regards, tom lane
