Re: Locking in PostgreSQL? - Mailing list pgsql-performance

From Erik Jones
Subject Re: Locking in PostgreSQL?
Date
Msg-id 45770754.8030500@myemma.com
Whole thread Raw
In response to Re: Locking in PostgreSQL?  (Casey Duncan <casey@pandora.com>)
List pgsql-performance
Casey Duncan wrote:
> 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
Or, come up with some kind of (pre)caching strategy for your updates
wherein you could then combine multiple updates to the same row into one
update.

--
erik jones <erik@myemma.com>
software development
emma(r)


pgsql-performance by date:

Previous
From: "Steinar H. Gunderson"
Date:
Subject: [offtopic] Word wrapping
Next
From: Michael Stone
Date:
Subject: Re: File Systems Compared