Skip site navigation (1) Skip section navigation (2)

Re: [WIP] shared row locks

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] shared row locks
Date: 2005-03-29 23:11:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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

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)

In response to

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2005-03-30 02:33:45
Subject: unused variable ShmemBootstrap
Previous:From: Peter EisentrautDate: 2005-03-29 20:35:50
Subject: Re: pgsql: Add URL of how to report bugs:

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group