On 2016-09-21 22:23:27 -0400, Tom Lane wrote: > 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".
Note that I'm explicitly *not* saying that. I just would like to see actual comparisons being made before investing significant amounts of code and related effort being invested in fixing the current hash table implementation. And I haven't seen a lot of that. If the result of that comparison is that hash-indexes actually perform very well: Great! > 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? The necessary work seems a good bit from finished. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
