Re: Shared row locking

On Mon, Dec 20, 2004 at 11:47:41AM -0500, Tom Lane wrote:

> To me, "performance buster" is better than "random, unrepeatable
> deadlock failures".  In any case, if we find we *can't* implement this
> in a non-performance-busting way, then it would be time enough to look
> at alternatives that force the user to manage the problem for us.

I am confused by this discussion.

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.


Some people seems to think 3 is better than 2.  What do they think of 1?


Some facts:

- DB2 implements 3 and some people have problems with deadlocks.

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

- I am interested in implementing 1, maybe 2.  Don't know about 3.

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)