Message-ID: <45770754.8030500@myemma.com>
Date: Wed, 06 Dec 2006 12:09:24 -0600
From: Erik Jones <erik@myemma.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Casey Duncan <casey@pandora.com>
Cc: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>,
	pgsql-general@postgresql.org, pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Locking in PostgreSQL?
References: <1165388652.6396.1.camel@panoramix>
	<433FC6DE-EF5C-493A-967C-C1B0F1882C23@pandora.com>
In-Reply-To: <433FC6DE-EF5C-493A-967C-C1B0F1882C23@pandora.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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)