On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Else, it will have to wait, using XactLockTableWait, for >the first transaction in the array that is still running. We can be >sure that no one will try to share-lock the tuple while we check the >btree because we hold an exclusive lock on the tuple's heap page's >buffer.
Do you really want to XactLockTableWait while holding an exclusive lock on a heap page? Or are you going to release the lock before entering the wait? >Thanks to tablespaces, it's very easy to create special Relations that >can be dealt with by standard buffer and storage manager, etc. I don't get how tablespaces would help. >The btree idea: >- does not need crash recovery. Maybe we could use a stripped down > version of nbtree. This could cause a maintanibility nightmare. It could be a nightmare if you simply duplicate and then modify the code. A better way would be to refactor nbtree to be able to handle btrees with different properties: . shared/private . logged/non-logged . flexible value data type. >- can't hold more than 300 or so simultaneous lockers (because of value > length, limited to 1/3 of a page). I doubt this is a real problem. Or you store each lock as a separate index tuple. If this is expected to be a problem because of many repeating key vaules, nbtree should be enhanced to support duplicate key compression, which might be a good thing per se. Servus Manfred ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
