Re: Shared row locking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared row locking
Date: 2004-12-20 18:34:21
Message-ID: 26479.1103567661@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> To solve the problem I want to solve, we have three orthogonal
> possibilities:

> 1. implement shared row locking using the ideas outlined in the mail
> starting this thread (pg_clog-like seems to be the winner, details TBD).

> 2. implement shared lock table spill-to-disk mechanism.

> 3. implement lock escalation.

Check.

> - 2 could have a performance impact, and we don't even know how to
> start. For example, what would be an algorithm to decide what locks
> to send to disk?

LRU, perhaps? That's all open for investigation still.

#1 could have a pretty serious performance impact, too. For small
numbers of FOR UPDATE locks (too few to force spill to disk) I would
expect #2 to substantially beat #1. #1 essentially imposes the worst
case performance at all times, whereas #2 degrades (at a currently
unknown rate) when there are lots and lots of FOR UPDATE locks.

Most of the applications I've seen don't take out that many FOR UPDATE
locks at once, so I'm unclear on the rationale for choosing a fixed-but-
poor performance curve over one that is fast for few locks and degrades
for many locks. Especially when the value of "many" is
user-configurable.

Furthermore, we have also seen issues with too many locks on ordinary
objects, which #2 would solve simultaneously.

So I feel that #2 is clearly the approach to try first. If we find that
we can't do spill-to-disk without serious performance degradation, then
I'd be inclined to try #1 next. I really don't care for the
user-visible semantics changes implied by #3 ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-12-20 19:04:46 Heads up: RC2 this evening
Previous Message Alvaro Herrera 2004-12-20 18:10:32 Re: multi-key index