On Thu, Sep 22, 2016 at 8:03 AM, 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.
>
I think it can be deduced from testing done till now. Basically, by
having index (btree/hash) on integer column can do the fair
comparison. The size of key will be same in both hash and btree
index. In such a case, if we know that hash index is performing
better in certain cases, then it is indication that it will perform
better in the scheme you are suggesting because it doesn't have extra
recheck in btree code which will further worsen the case for btree.
> If the result of that
> comparison is that hash-indexes actually perform very well: Great!
>
>
>> always be superior, I don't see how it follows that we should refuse to
>> commit work that's already been done. Is committing it somehow going to
>> prevent work on the btree-wrapper approach?
>
> The necessary work seems a good bit from finished.
>
Are you saying this about WAL patch? If yes, then even if it is still
away from being in shape to committed, there is a lot of effort being
put in to taking into its current stage and it is not in bad shape
either. It has survived lot of testing, there are still some bugs
which we are fixing.
One more thing, I want to say that don't assume that all people
involved in current development of hash indexes or further development
on it will run away once the code is committed and the responsibility
of maintenance will be on other senior members of community.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com