Pailloncy Jean-Gerard wrote:
> You should have a look to this thread
> http://archives.postgresql.org/pgsql-hackers/2005-02/msg00263.php
>
> Take a look at this paper about "lock-free parallel hash table"
> http://www.cs.rug.nl/~wim/mechver/hashtable/
Is this relevant? Hash indexes are on-disk data structures, so ISTM
lock-free algorithms aren't really applicable.
(BTW, is poor concurrency really the biggest issue with hash indexes? If
so, there is some low-hanging fruit that I noticed a few years ago, but
never got around to fixing: _hash_doinsert() write-locks the hash
metapage on every insertion merely to increment a tuple counter. This
could be improved by just acquiring the lock with probability 1/k, and
incrementing the counter k times -- or some similar statistical
approximation. IMHO there are bigger issues with hash indexes, like the
lack of WAL safety, the very slow index build times, and their
relatively poor performance -- i.e. no better than btree for any
workload I've seen. If someone wants to step up to the plate and fix
some of that, I'll improve hash index concurrency -- any takers? :-) )
-Neil
