On 2016-09-23 15:19:14 -0400, Robert Haas wrote: > 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.
Huh. I think we make such arguments *ALL THE TIME*. Anyway, I don't see much point in continuing to discuss this, I'm clearly in the minority. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers