On 2016-09-23 15:19:14 -0400, Robert Haas wrote:
> On Wed, Sep 21, 2016 at 10:33 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-09-21 22:23:27 -0400, Tom Lane wrote:
> >> Andres Freund <andres@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.