Tom Lane <tgl@xxxxxxxxxxxxx> 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. -- greg ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
