Re: row level locking

From: "Sibte Abbas" <sibtay(at)gmail(dot)com>
To: "Mark Steben" <msteben(at)autorevenue(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: row level locking
Date: 2007-07-20 18:54:55
Message-ID: bd6a35510707201154r62884d1cp106aa1c88d4f46ec@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 7/20/07, Mark Steben <msteben(at)autorevenue(dot)com> wrote:
>
> Hi listers,
>
> I have a table that is accessed by only one transaction. It has 1500 rows
> each time that it processes
>
> This transaction. As soon as this transaction ends, it waits 10 seconds and
> starts again.
>
> It has another maximum 1500 rows loaded. .
>
>
>
> My question is this: I believe a RowExclusive level lock is acquired 1500
> times during each transaction.

What type operations does the transaction performs on the table?

An exclusive row level lock is acquired only:

i) when a row is being updated, deleted or marked for deletion (Implicit lock)
ii) when SELECT FOR UPDATE query is executed on the table (to acquire
a share lock you can use SELECT FOR SHARE) (Explicit lock)

>
> Is this true? Is there a way to disable RowExclusive locks and reduce
> overhead since only this transaction

Consider running postgresql in single user mode. This would eradicate
all the Interprocess communication overheads.

>
> Accesses this table. I know there are ways to specify locking levels in
> other DBMSs. To page or table levels.
>

Postgresql handles page level locks implicitly, users do not have any
control over them.

regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Jessica Richard 2007-07-20 19:00:18 select a range of data
Previous Message Mark Steben 2007-07-20 18:19:36 row level locking