Re: New feature: skip row locks when table is locked.
От | Jeff Davis |
---|---|
Тема | Re: New feature: skip row locks when table is locked. |
Дата | |
Msg-id | 1304027077.11097.17.camel@jdavis-ux.asterdata.local обсуждение исходный текст |
Ответ на | New feature: skip row locks when table is locked. (pasman pasmański <pasman.p@gmail.com>) |
Ответы |
Re: New feature: skip row locks when table is locked.
|
Список | pgsql-general |
On Thu, 2011-04-28 at 07:29 +0200, pasman pasmański wrote: > Hi. Yesterday i have an idea, that sometimes row locks may be skipped, > when table is already locked with LOCK command. It may to reduce an > overhead from row locks. > What do you think about it? The table-level lock mode would need to be high enough to conflict with SELECT FOR UPDATE to prevent concurrent SELECT FOR UPDATEs from happening (or a SELECT FOR UPDATE and SELECT FOR SHARE happening concurrently). From: http://www.postgresql.org/docs/9.0/static/explicit-locking.html It looks like you'd need either EXCLUSIVE or ACCESS EXCLUSIVE lock mode as the table-level lock in order to skip the row-level lock. So, I think your optimization would work (at least I can't think of anything wrong with it), so long as the table-level lock is at least as strong as EXCLUSIVE. Seems fairly minor though -- most people would not be using row locks if they already have an EXCLUSIVE lock on the table. Do you have a use-case in mind? Regards, Jeff Davis
В списке pgsql-general по дате отправления: