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