Stephen Robert Norris <srn@commsecure.com.au> writes:
> We've just discovered a rather nasty feature of hashes, namely that
> simultaneous reads & writes to a single row will deadlock if there
> is a hash index on the table.
The hash index code is documented to be subject to deadlocks, but I've
never looked into it to discover the exact conditions that cause
problems.
I could maybe get excited about fixing this if I could think of one
single application wherein a hash index is superior to a btree index.
But I can't, so I think the hash index code should be deprecated and
left to die quietly.
(This para strictly MHO:) In the long run the btree and GIST index types
will probably be the only two of the four present types that remain
supported. Since btree dominates hash and GIST dominates rtree for
functionality, it's hard to see why we should expend development effort
on the other two. Right now, GIST isn't really ready for prime time
either (no support for concurrent updates), but it does things that
btree can't do, so there's reason to expend work on it.
As of today, if you're concerned about concurrent updates, btree is the
only Postgres index type you should be using.
regards, tom lane
