Re: bitmap AM design
От | Neil Conway |
---|---|
Тема | Re: bitmap AM design |
Дата | |
Msg-id | 42282E97.9070703@samurai.com обсуждение исходный текст |
Ответ на | Re: bitmap AM design (Pailloncy Jean-Gerard <jg@rilk.com>) |
Ответы |
Re: bitmap AM design
Re: bitmap AM design Re: bitmap AM design |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: