Skip site navigation (1) Skip section navigation (2)

Re: New feature: skip row locks when table is locked.

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pasman pasmański <pasman(dot)p(at)gmail(dot)com>
Cc: Pgsql-general(at)postgresql(dot)org
Subject: Re: New feature: skip row locks when table is locked.
Date: 2011-04-28 21:44:37
Message-ID: 1304027077.11097.17.camel@jdavis-ux.asterdata.local (view raw or flat)
Thread:
Lists: 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


In response to

Responses

pgsql-general by date

Next:From: Basil BourqueDate: 2011-04-28 22:27:04
Subject: Re: SSDs with Postgresql?
Previous:From: Karsten HilbertDate: 2011-04-28 21:07:42
Subject: Re: pervasiveness of surrogate (also called synthetic) keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group