Neil Conway <neil.con...@gmail.com> wrote: > Tracking the read sets of each transaction would be very expensive. > Worse still, that information needs to be kept around after > end-of-transaction, which raises questions about where it should be > stored and how it should be cleaned up. Note that the benchmarks in > the paper involve transactions that perform "a small number of > simple read and update operations", which reduces the bookkeeping > overhead. I know that some of the simplifying assumptions listed in 3.1 do not currently hold for PostgreSQL. A prerequisite for using the algorithm would be to make them hold for PostgreSQL, or find some way to work around their absence. I hope people will read the paper and mull it over, but these assumptions are probably the crux or whether this enhancement is feasible. I guess it would be best to throw that much out to the list for discussion. To quote: > 1. For any data item x, we can efficiently get the list of > locks held on x. > 2. For any lock l in the system, we can efficiently get > l.owner, the transaction object that requested the lock. > 3. For any version xt of a data item in the system, we > can efficiently get xt.creator, the transaction object > that created that version. > 4. When *nding a version of item x valid at some given > timestamp, we can efficiently get the list of other ver- > sions of x that have later timestamps. Based on my limited understanding, I don't get the impression 2 or 3 are a problem. I'm assuming that we would use the structures which back the pg_locks view for the SIREAD locks implicit in 1, possibly with some scope escalation as counts for a table rise (row to page to extent to table). This may require a larger allocation for this information by those wanting to use serializable transactions. I'm not sure how 4 could be handled. I don't know how much work would be required to track the transaction information listed in section 4.1 (or its functional equivalent). I'd be happy to hear the opinion of those more familiar with the internals than I. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers