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 decide what locks
to send to disk?
- I am interested in implementing 1, maybe 2. Don't know about 3.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)
---------------------------(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
