Christopher Kings-Lynne wrote: > > I think the speed complaint I was just raising could possibly be > > answered by setting an infomask bit indicating that the row might > > be present in a separate table of active row locks. (I'm not sure > > how the bit would get cleared without race conditions, but let's > > suppose that can be done.) A little hashing, a little spill-to-disk > > logic, and it might be done. But that's just handwaving... anyone > > want to try to fill in the details? > > I vote Alvaro :) This stuff is way out of my league - I'm just the > ideas man :D > > Either way - Bruce, did you want to add a summary of these ideas to the > TODO?
OK, TODO updated: * Implement dirty reads or shared row locks and use them in RI triggers Adding shared locks requires recording the table/rows numbers in a shared area, and this could potentially be a large amount of data. One idea is to store the table/row numbers in a separate table and set a bit on the row indicating looking in this new table is required to find any shared row locks. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
