"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> I'll push forward on reviewing and testing Xiao's hash index
> improvements for inclusion into core. Though, someone will still need
> to review my stuff.
I think what the hash index patch really needs is some performance
testing. I'm willing to take responsibility for the code being okay
or not, but I haven't got any production-grade hardware to do realistic
performance tests on. I'd like to see a few more scenarios tested than
the one provided so far: in particular, wide vs narrow index keys and
good vs bad key distributions.
It strikes me that there's an intermediate posture that the patch
doesn't provide: namely, store *both* hash code and original index key
in each index entry. This would make the index larger rather than
smaller, but you could still do the intra-page sort by hash code,
which I think is likely a big win. In exchange for the bigger index
you'd avoid fruitless trips to the heap for chance hashcode matches.
So it seems far from clear to me that the hash-code-only solution is
necessarily the best.
If anyone is willing to do comparative performance testing, I'll
volunteer to make up two variant patches that do it both ways and
are otherwise equivalent.
(I wouldn't be too surprised if testing shows that each way could be
a win depending on the situation. In that case we could think about
how to provide a switch to let users pick the method. But for the
moment let's just test two separate patches.)
regards, tom lane
