On Mon, Mar 28, 2005 at 11:18:05PM -0500, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> 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 (<[EMAIL PROTECTED]>) "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) ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org