From: | ktm(at)rice(dot)edu |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hash Indexes |
Date: | 2016-10-01 16:58:02 |
Message-ID: | 20161001115802.Horde.y2HrGcaIURc63RfXM-f5Ew1@webmail.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de>:
> On 2016-09-30 17:39:04 +0100, Peter Geoghegan wrote:
>> On Fri, Sep 30, 2016 at 4:46 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2016-10-01 17:55:15 | Re: Show hash / bitmap sizes in EXPLAIN ANALYZE? |
Previous Message | Tom Lane | 2016-10-01 16:23:03 | Re: [PATCH] parallel & isolated makefile for plpython |