On Wed, May 30, 2012 at 3:49 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 30 May 2012 04:54, Robert Haas <robertmh...@gmail.com> wrote: > >>> This was a hobby horse of mine a couple of years ago, but I never got >>> much traction. The main question I have is, what do we even want hash >>> indexes to be? NBTree is very good, has been extensively optimized, >>> and extensively tested. If there is a niche left for hash indexes, >>> what is it? Is it just very large keys which don't do well in BTrees, >>> or something else? >> >> Well, TBH, I was hoping they'd be faster than btree. > > They are faster than btree in terms of response time, just not as concurrent. > > Right now if you have a table bigger than RAM with direct access then > hash indexes will be faster, but I agree that the use case is not > large enough to be worth spending the time to improve hash indexes.
Yeah -- for i/o bound lookups hash indexes can be around 2x faster for large tables than a btree-wrapping-digest index. I confirmed this a few months back when openly conjecturing if the hash index code should be in fact replaced with a btree wrapper. I've never used a hash index in a production database. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
