Skip site navigation (1) Skip section navigation (2)

Re: bitmap AM design

From: Neil Conway <neilc(at)samurai(dot)com>
To: Pailloncy Jean-Gerard <jg(at)rilk(dot)com>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, pgsql(at)mohawksoft(dot)com,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>,"Victor Y(dot) Yegorov" <viy(at)mits(dot)lv>
Subject: Re: bitmap AM design
Date: 2005-03-04 09:47:03
Message-ID: 42282E97.9070703@samurai.com (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-hackers by date

Next:From: pgsqlDate: 2005-03-04 12:29:33
Subject: Re: bitmap AM design
Previous:From: Pailloncy Jean-GerardDate: 2005-03-04 08:38:29
Subject: Re: bitmap AM design

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group