| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
| Cc: | "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>, "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 16:47:41 |
| Message-ID: | 20019.1103561261@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> I may be over my head here, but I think lock spillover is dangerous. In
> the extreme situations where this would happen, it would be a real
> performance buster. Personally, I would rather see locks escalate when
> the table gets full, or at least allow this as a configuration
> parameter.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2004-12-20 17:58:21 | multi-key index |
| Previous Message | Merlin Moncure | 2004-12-20 15:58:31 | Re: Shared row locking |