From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shared row locking |
Date: | 2004-12-20 18:09:24 |
Message-ID: | 20041220180924.GC14818@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-12-20 18:10:32 | Re: multi-key index |
Previous Message | Bruce Momjian | 2004-12-20 18:03:05 | Re: multi-key index |