Re: Hash Indexes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Hash Indexes
Date
Msg-id 20160920235536.GA11920@momjian.us
Whole thread Raw
In response to Re: Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Hash Indexes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Sep 19, 2016 at 03:50:38PM -0400, Robert Haas wrote:
> It will probably have some bugs, but they probably won't be worse than
> the status quo:
> 
> WARNING: hash indexes are not WAL-logged and their use is discouraged
> 
> Personally, I think it's outright embarrassing that we've had that
> limitation for years; it boils down to "hey, we have this feature but
> it doesn't work", which is a pretty crummy position for the world's
> most advanced open-source database to take.

No question.  We inherited the technical dept of hash indexes 20 years
ago and haven't really solved it yet.  We keep making incremental
improvements, which keeps it from being removed, but hash is still far
behind other index types.

> > I'm rather unenthused about having a hash index implementation that's
> > mildly better in some corner cases, but otherwise doesn't have much
> > benefit. That'll mean we'll have to step up our user education a lot,
> > and we'll have to maintain something for little benefit.
> 
> If it turns out that it has little benefit, then we don't really need
> to step up our user education.  People can just keep using btree like

The big problem is people coming from other databases and assuming our
hash indexes have the same benefits over btree that exist in some other
database software.  The 9.5 warning at least helps with that.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: less expensive pg_buffercache on big shmem
Next
From: Peter Eisentraut
Date:
Subject: Re: Exclude schema during pg_restore