Thread: Do we still have locking problems with concurrent users of hash tables?
Hi all, One of the things which the AS3AP benchmark does is have multiple users access a table with hash indexes on it. With the OSDB (Open Source Database Benchmark: http://osdb.sf.net) we've found on PG 7.1 that multiple clients hitting a table using a hash index generates locking problems. I remember Tom mentioning that this is a known thing, but I'm not sure if this has been fixed since then. Does anyone have any ideas? If not, would someone be willing to take the time to fix it? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Justin Clift wrote: > Hi all, > > One of the things which the AS3AP benchmark does is have multiple users > access a table with hash indexes on it. > > With the OSDB (Open Source Database Benchmark: http://osdb.sf.net) we've > found on PG 7.1 that multiple clients hitting a table using a hash index > generates locking problems. I remember Tom mentioning that this is a > known thing, but I'm not sure if this has been fixed since then. > > Does anyone have any ideas? If not, would someone be willing to take > the time to fix it? It has not been fixed. One TODO item is to either stop mentioning hash at all or get it improved. We have been sitting on the fence for too long. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 2002-03-05 at 21:59, Bruce Momjian wrote: > Justin Clift wrote: > > Hi all, > > > > One of the things which the AS3AP benchmark does is have multiple users > > access a table with hash indexes on it. > > > > With the OSDB (Open Source Database Benchmark: http://osdb.sf.net) we've > > found on PG 7.1 that multiple clients hitting a table using a hash index > > generates locking problems. I remember Tom mentioning that this is a > > known thing, but I'm not sure if this has been fixed since then. No, it hasn't been fixed yet. > > Does anyone have any ideas? If not, would someone be willing to take > > the time to fix it? > > It has not been fixed. One TODO item is to either stop mentioning hash > at all or get it improved. We have been sitting on the fence for too > long. I'll be working on fixing this. I'm also going to try to add more features to the hash index implementation: for example, allow UNIQUE hash indexes, hash indexes over multiple keys, etc. My first improvement to the hash code, replacing the hash function with a better one, is on the unapplied patches list and should be in CVS soon. Bruce, can you add my name to the TODO list next to this item? BTW, does anyone have any tips for debugging deadlock conditions? I normally debug problems by running a backend under gdb in standalone mode, but that obviously won't help for this problem. Any further advice on improving hash index concurrency would be very welcome... Justin: Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
> > > Does anyone have any ideas? If not, would someone be willing to take > > > the time to fix it? > > > > It has not been fixed. One TODO item is to either stop mentioning hash > > at all or get it improved. We have been sitting on the fence for too > > long. > > I'll be working on fixing this. I'm also going to try to add more > features to the hash index implementation: for example, allow UNIQUE > hash indexes, hash indexes over multiple keys, etc. My first improvement > to the hash code, replacing the hash function with a better one, is on > the unapplied patches list and should be in CVS soon. Bruce, can you add > my name to the TODO list next to this item? TODO updated. Done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> It has not been fixed. One TODO item is to either stop mentioning hash > at all or get it improved. We have been sitting on the fence for too > long. Could someone give me a quick rundown on where using a hash index would be advantageous over using a btree index? Thanks, Chris
Christopher Kings-Lynne wrote: > > It has not been fixed. One TODO item is to either stop mentioning hash > > at all or get it improved. We have been sitting on the fence for too > > long. > > Could someone give me a quick rundown on where using a hash index would be > advantageous over using a btree index? That is the issue, right now, there is little or no advantage. If we can improve it, it may become better than btree for cases where you are only doing equal comparisons, rather than > which only btree can do. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Awesome! Thanks Neil. :-) Regards and best wishes, Justin Clift Neil Conway wrote: > > On Tue, 2002-03-05 at 21:59, Bruce Momjian wrote: > > Justin Clift wrote: > > > Hi all, > > > > > > One of the things which the AS3AP benchmark does is have multiple users > > > access a table with hash indexes on it. > > > > > > With the OSDB (Open Source Database Benchmark: http://osdb.sf.net) we've > > > found on PG 7.1 that multiple clients hitting a table using a hash index > > > generates locking problems. I remember Tom mentioning that this is a > > > known thing, but I'm not sure if this has been fixed since then. > > No, it hasn't been fixed yet. > > > > Does anyone have any ideas? If not, would someone be willing to take > > > the time to fix it? > > > > It has not been fixed. One TODO item is to either stop mentioning hash > > at all or get it improved. We have been sitting on the fence for too > > long. > > I'll be working on fixing this. I'm also going to try to add more > features to the hash index implementation: for example, allow UNIQUE > hash indexes, hash indexes over multiple keys, etc. My first improvement > to the hash code, replacing the hash function with a better one, is on > the unapplied patches list and should be in CVS soon. Bruce, can you add > my name to the TODO list next to this item? > > BTW, does anyone have any tips for debugging deadlock conditions? I > normally debug problems by running a backend under gdb in standalone > mode, but that obviously won't help for this problem. Any further advice > on improving hash index concurrency would be very welcome... > > Justin: > > Cheers, > > Neil > > -- > Neil Conway <neilconway@rogers.com> > PGP Key ID: DB3C29FC -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Justin Clift writes: > One of the things which the AS3AP benchmark does is have multiple users > access a table with hash indexes on it. In a closed-source system, we could get away with making hash and B-tree indexes the same internally and tell onlookers that they're different, so as to satisfy the AS3AP requirements. ;-) -- Peter Eisentraut peter_e@gmx.net