On Fri, Sep 30, 2016 at 4:46 PM, Robert Haas <robertmh...@gmail.com> wrote: > I would just be very disappointed if, after the amount of work that > Amit and others have put into this project, the code gets rejected > because somebody thinks a different project would have been more worth > doing.
I wouldn't presume to tell anyone else how to spend their time, and am not concerned about this making the hash index code any less useful from the user's perspective. If this is how we remove the wart of hash indexes not being WAL-logged, that's fine by me. I am trying to be helpful. > As Tom said upthread: $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".$ I > think that's correct and a sufficiently-good reason to pursue this > work, regardless of the merits (or lack of merits) of hash-over-btree. I don't think that "O(1) index lookups" is a useful guarantee with a very expensive constant factor. Amit said: "I think any discussion on whether we should consider not to improve current hash indexes is only meaningful if some one has a code which can prove both theoretically and practically that it is better than hash indexes for all usages", so I think that he shares this view. > The fact that we have hash indexes already and cannot remove them > because too much other code depends on hash opclasses is also, in my > opinion, a sufficiently good reason to pursue improving them. I think that Andres was suggesting that hash index opclasses would be usable with hash-over-btree, so you might still not end up with the wart of having hash opclasses without hash indexes (an idea that has been proposed and rejected at least once before now). Andres? To be clear: I haven't expressed any opinion on this patch. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
