On Wed, Sep 21, 2016 at 10:33 PM, Andres Freund <and...@anarazel.de> wrote: > 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!
Yeah, I just don't agree with that. I don't think we have any policy that you can't develop A and get it committed unless you try every alternative that some other community member thinks might be better in the long run first. If we adopt such a policy, we'll have no developers and no new features. Also, in this particular case, I think there's no evidence that the alternative you are proposing would actually be better or less work to maintain. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
