Re: [PERFORM] Locking in PostgreSQL? - Mailing list pgsql-general

From Casey Duncan
Subject Re: [PERFORM] Locking in PostgreSQL?
Date
Msg-id 433FC6DE-EF5C-493A-967C-C1B0F1882C23@pandora.com
Whole thread Raw
In response to Locking in PostgreSQL?  (Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>)
Responses Re: [PERFORM] Locking in PostgreSQL?  (Erik Jones <erik@myemma.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Devrim GUNDUZ
Date:
Subject: Re: Error in installing compat-postgresql-libs rpm
Next
From: Erik Jones
Date:
Subject: Re: [PERFORM] Locking in PostgreSQL?