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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
