Re: Re: Shared row locking

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote on 20.12.2004, 19:34:21:
> Alvaro Herrera 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.

Agreed.

[My gut feeling would be against another permanent on-disk structure,
since this is one more thing for a user to delete "to save space"
etc...]

> 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 agree. We need to understand what type of application logic we are
coding for.

In general, I agree with Tom: I haven't seen many programs that use
extended SELECT FOR UPDATE logic. However, the ones I have seen have
been batch style programs written using a whole-table cursor - these
latter ones have been designed for the cursor stability approach.

It would be much better to analyze one or more representative
application suites to understand which option to pick. Without a set of
programs, or some driving force, the wrong one could be picked.

Spill-to-disk would not be that bad, since WARNINGs could appear in the
log. That's much better than doing a lock escalation, definitely.

Best Regards, Simon Riggs