Re: Hash Indexes

Andres Freund <andres@anarazel.de>:

> On 2016-09-30 17:39:04 +0100, Peter Geoghegan wrote:
>> On Fri, Sep 30, 2016 at 4:46 PM, Robert Haas <robertmhaas@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.
>
> Me neither.
>
> I'm concerned that this is a heck of a lot of work, and I don't think
> we've reached the end of it by a good bit. I think it would have, and
> probably still is, a more efficient use of time to go for the
> hash-via-btree method, and rip out the current hash indexes.  But that's
> just me.
>
> I find it more than a bit odd to be accused of trying to waste others
> time by saying this, and that this is too late because time has already
> been invested. Especially the latter never has been a standard in the
> community, and while excruciatingly painful when one is the person(s)
> having invested the time, it probably shouldn't be.
>
>
>> > 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?
>
> Yes, that was what I was pretty much thinking. I was kind of guessing
> that this might be easiest implemented as a separate AM ("hash2" ;))
> that's just a layer ontop of nbtree.
>
> Greetings,
>
> Andres Freund

Hi,

There have been benchmarks posted over the years were even the non-WAL  
logged hash out performed the btree usage variant. You cannot argue  
against O(1) algorithm behavior. We need to have a usable hash index  
so that others can help improve it.

My 2 cents.

Regards,
Ken