From: Robert Haas <robertmhaas@gmail.com>
To: Matt Burke <mattblists@icritical.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slowing UPDATEs inside a transaction
Date: Fri, 4 Mar 2011 09:20:46 -0500
Message-ID: <AANLkTikCadoAC64-R8NH+RMGtJCvDPtk59ejFLm=_d+W@mail.gmail.com> (raw)
In-Reply-To: <4D70AF32.7020706@icritical.com>
References: <4D6FA208.1040800@icritical.com>
<AANLkTikbvc9KHd98=3oeenGmmGq8Qi+ng4eRBGHffpNh@mail.gmail.com>
<4D70AF32.7020706@icritical.com>
On Fri, Mar 4, 2011 at 4:21 AM, Matt Burke <mattblists@icritical.com> wrote:
> 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?
Because in theory you could have a cursor open. You could open a
cursor, start to read from it, then make an update. Now the cursor
needs to see things as they were before the update.
We might be able to do some optimization here if we had some
infrastructure to detect when a backend has no registered snapshots
with a command-ID less than the command-ID of the currently active
snapshot, but nobody's put in the effort to figure out exactly what's
involved and whether it makes sense. It's a problem I'm interested
in, but #(needed round-tuits) > #(actual round-tuits).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: robertmhaas@gmail.com, mattblists@icritical.com
Subject: Re: Slowing UPDATEs inside a transaction
In-Reply-To: <AANLkTikCadoAC64-R8NH+RMGtJCvDPtk59ejFLm=_d+W@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox