> As I remember the implementation problem is that we do an exclusive row > lock right now by putting the transaction id on the row and set a > special row-lock bit in the tuple. Shared locks need to store multiple > transaction ids, and that is where we are stuck. Shared memory is of > finite size, and the number of proc/row combinations is infinite, so it > seems we will need some shared stucture with backing store to disk, and > that will be slow. > > You know the maximum number of backends on startup, but I don't see how > that helps us. If we could somehow know the unique combinations of > those backend ids that would be used for any row, we could reserve a > range of transactions ids to map them, but the number of combinations is > too large. > > Our xid/command-counter is currently 64 bits, so if we only had a > maximum of 64 backends, we could use those bits to mark the backends > holding the locks rather than put the xid in there. Of course, the > maximum number backends can change over time, so that isn't really a > solution but more a brainstorm, but I do think shared memory bitmaps > might be in the final solution. > > One idea would be to allocate 10k of shared memory for a shared lock > bitmap. Assuming a max 100 backend, that is 2500 lock combinations, > numbered 0-2499. We would put the bitmap number on the rows rather than > the xid. Of course, problems are that there are only 2500 combinations > supported, and transactions have to get an exclusive lock on transaction > commit to clear their backend bits from the bitmap table so the rows can > be reused. Another refinement would be to use the row xid to store > either the xid for single backend locks, and use the bitmap table number > only when there is sharing of row locks by multiple backends. That > might reduce the contention on the bitmap table. If a backend wasn't > involved in shared locks, its bit wouldn't be set in the bitmap table > and it has nothing to do, and it can read the table without a lock.
The way I understand it, is that you're having trouble storing all of the xids in the row; right now you just store one and mark it "locked". If you were able to store several, but not necessarily all xids in all cases, wouldn't that be a big improvement? The xids not in the list would lock, as they do now, and the ones in the list would show an improvement by sharing the lock, right? Otherwise I don't entirely understand what you're saying. Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings