Re: [WIP] shared row locks

On Mon, Mar 28, 2005 at 11:18:05PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > 1. To examine a tuple one must first call LockTuple, which grabs a pin
> > and lock in the buffer. The buffer lock is released right away, but the
> > pin is kept.
>
> Surely you don't mean that *every* access to a tuple now has to go
> through the lock manager :-(. Have you done any performance testing?

Ok, I fixed the problem (basically, the old locking rules still apply:
would-be tuple modifiers need to hold locks on the buffer as well as on
the tuples). The changes to the patch are not considerable so I won't
post it again.

I played with pgbench a bit and was horrified at first because I was
taking a 25% perf. hit. Then I remembered that I had compiled
backend/access/heap with -O0 ... doh. So I recompiled and now I can't
measure any difference.

Right now I'm figuring out a way of making the lock queue go to disk.
I think I'll make a LRU list, and when we are short in space the LRU locks
will be replaced by a placeholder that will only keep the LOCKTAG and
info necessary to retrieve it from disk. The LOCK struct is 132 bytes
long on my platform, and the placeholder would be 20 bytes (LOCKTAG +
int), so by storing a couple of locks there's room for another one
(that's the simple theory that ignores memory fragmentation issues).
I'm just starting to figure this out so if there are comments I welcome
them.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Hay que recordar que la existencia en el cosmos, y particularmente la
elaboración de civilizaciones dentre de él no son, por desgracia,
nada idílicas" (Ijon Tichy)