Alvaro Herrera <alvherre@dcc.uchile.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?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Mon, Mar 28, 2005 at 11:18:05PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.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 :-(.

Hmm. Only updates (delete/select for update) of the tuples, not a
vanilla select. Is that what you mean? I realize I left out the fact
that the old rule still applies when dealing with standard select.

Oh, that's a big hole in the reasoning. The buffer has to be locked
still in 3 because of this. Will fix.

> Have you done any performance testing?

Not really. Will do tomorrow.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La principal característica humana es la tontería"
(Augusto Monterroso)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Mon, Mar 28, 2005 at 11:18:05PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.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[@]dcc.uchile.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)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org