On Fri, Apr 01, 2005 at 11:02:36PM -0500, Tom Lane wrote:
[Cc: to -hackers]
> We currently store tuple locks on the same page as the tuples (ie, in
> the tuple headers) and need no extra locks to do so. Certainly it
> still has to have a spill mechanism, but the thought that is attractive
> to me is that until you are forced to spill, you do not have to take any
> system-wide lock, only a page-level lock. So it could have very good
> average performance.
If we go this way maybe we should abandon the idea of using the standard
lock manager to lock tuples, which is what can be found on the patch I
posted. Or maybe not, and just have the lock manager store the locks on
the page himself -- but it will have to know about the buffer, so it
will be in some sense a break in opacity (of API between the two).
One possible way to do it would be having a OffsetNumber stored in the
page header, and if it's not InvalidOffsetNumber then it points to a
"tuple" that holds
struct
{
OffsetNumber nextLock;
LOCK lock
}
So a locker would check the chain of locks and stop when it sees
InvalidOffsetNumber.
If there is no free space on the page, what should we do? Store the
lock into the main hash table?
Another problem would be the XLog. On heap operations, do we register
exactly where (position in the page) a tuple was stored, or just the
fact that it was stored? If the latter, then there's no problem. If
the former, then on the next REDO the records wouldn't match (==> PANIC)
-- unless we logged the lockings as well.
Reading the code I see we do log the offset numbers, so that's a problem
:-( ... maybe we could work around that by moving the pd_lower without
using line pointers; not sure if that's doable.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Porque Kim no hacia nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
