Heikki Linnakangas wrote:
> Tom Lane wrote:
>> 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.
>
> True, that's the "roughly" part. It does indeed depend on your schema.
> As a data point, here's the index sizes (in pages) of a 140 warehouse
> TPC-C database:
Ah, I see now that you didn't (necessarily) mean that the clustering
becomes inefficient at reducing the index size on wider tables, but that
there's much more heap pages than leaf pages in a normal index. That's
true, you might not want to use clustered index in that case, to allow
index-only scans. If we had that feature, that is.
Often, though, when using index-only scans, columns are added to the
index to allow them to be returned in an index-only scans. That narrows
the gap a bit.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
