Re: [PERFORM] Locking in PostgreSQL?

From: Casey Duncan <casey(at)pandora(dot)com>
To: Joost Kraaijeveld <J(dot)Kraaijeveld(at)Askesis(dot)nl>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Locking in PostgreSQL?
Date: 2006-12-06 17:58:37
Message-ID: 433FC6DE-EF5C-493A-967C-C1B0F1882C23@pandora.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Dec 5, 2006, at 11:04 PM, Joost Kraaijeveld wrote:

> Does PostgreSQL lock the entire row in a table if I update only 1
> column?

Know that updating 1 column is actually updating the whole row. So if
one transaction updates column A of a row, it will block another
concurrent transaction that tries to update column B of the same row.
As was mentioned however, neither of these transactions block others
reading the row in question, though they see the row as it existed
before the updates until those update transactions commit.

If you know that your application will suffer excessive update
contention trying to update different columns of the same row, you
could consider splitting the columns into separate tables. This is an
optimization to favor write contention over read performance (since
you would likely need to join the tables when selecting) and I
wouldn't do it speculatively. I'd only do it if profiling the
application demonstrated significantly better performance with two
tables.

-Casey

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2006-12-06 18:09:24 Re: [PERFORM] Locking in PostgreSQL?
Previous Message Devrim GUNDUZ 2006-12-06 17:33:07 Re: Error in installing compat-postgresql-libs rpm

Browse pgsql-performance by date

  From Date Subject
Next Message Arnaud Lesauvage 2006-12-06 17:59:12 Re: File Systems Compared
Previous Message Rajesh Kumar Mallah 2006-12-06 17:47:10 Re: VACUUM FULL does not works.......