Andres Freund <andres@anarazel.de> writes:
> Sure. But that can be addressed, with a lot less effort than fixing and
> maintaining the hash indexes, by adding the ability to do that
> transparently using btree indexes + a recheck internally. How that
> compares efficiency-wise is unclear as of now. But I do think it's
> something we should measure before committing the new code.
TBH, I think we should reject that argument out of hand. If someone
wants to spend time developing a hash-wrapper-around-btree AM, they're
welcome to do so. But to kick the hash AM as such to the curb is to say
"sorry, there will never be O(1) index lookups in Postgres".
It's certainly conceivable that it's impossible to get decent performance
out of hash indexes, but I do not agree that we should simply stop trying.
Even if I granted the unproven premise that use-a-btree-on-hash-codes will
always be superior, I don't see how it follows that we should refuse to
commit work that's already been done. Is committing it somehow going to
prevent work on the btree-wrapper approach?
regards, tom lane