Tom Lane <[EMAIL PROTECTED]> writes:

> However: what about storing the things in hashcode order?  Ordering uint32s
> doesn't seem like any big conceptual problem.
> I think that efficient implementation of this would require explicitly
> storing the hash code for each index entry, which we don't do now, but
> it seems justifiable on multiple grounds --- besides this point, the
> search could avoid doing the data-type-specific comparison if the hash
> code isn't equal.

It seems that means doubling the size of the hash index. That's a pretty big
i/o to cpu tradeoff. 

What if the hash index stored *only* the hash code? That could be useful for
indexing large datatypes that would otherwise create large indexes. A good
hash function should have a pretty low collision rate anyways so the
occasional extra i/o should more than be outweighed by the decrease in i/o
needed to use the index.


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to