Alvaro Herrera <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend