Neil Conway <neil.conway@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
