Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers