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. 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