Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to