Message-ID: <4D70AF32.7020706@icritical.com>
Date: Fri, 04 Mar 2011 09:21:54 +0000
From: Matt Burke <mattblists@icritical.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100704)
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Slowing UPDATEs inside a transaction
References: <4D6FA208.1040800@icritical.com>
	<AANLkTikbvc9KHd98=3oeenGmmGq8Qi+ng4eRBGHffpNh@mail.gmail.com>
In-Reply-To: <AANLkTikbvc9KHd98=3oeenGmmGq8Qi+ng4eRBGHffpNh@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Robert Haas wrote:
> Old row versions have to be kept around until they're no longer of 
> interest to any still-running transaction.

Thanks for the explanation.

Regarding the snippet above, why would the intermediate history of
multiply-modified uncommitted rows be of interest to anything, or is the
current behaviour simply "cheaper" overall in terms of cpu/developer time?


-- 
 
The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. 

Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation.

Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.

------------------------------------------------------------
This message has been scanned for security threats by iCritical.
    For further information, please visit www.icritical.com
------------------------------------------------------------