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
amountof data. One idea is to store the table/row numbers in a separate table and set a bit on the row indicating
lookingin this new table is required to find any shared row locks.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
