On Fri, Mar 4, 2011 at 4:21 AM, Matt Burke <mattblists@xxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
