On 4 December 2015 at 06:41, Robert Haas <robertmh...@gmail.com> wrote:
> > I think there are ways to reduce the cost of this. Some distributed > systems have solved it by retreating from snapshot isolation and going > back to using locks. This can improve scalability if you've got lots > of transactions but they're very short and rarely touch the same data. > Locking individual data elements (or partitions) doesn't require a > central system that knows about all commits - each individual node can > just release locks for each transaction as it completes. More > generally, if you could avoid having to make a decision about whether > transaction A precedes or follows transaction B unless transaction A > and B actually touch the same data - an idea we already use for SSI - > then you could get much better scalability. But I doubt that can be > made to work without a deeper rethink of our transaction system. > Something I've seen thrown about is the idea of lazy snapshots. Using SSI-like facilities you keep track of transaction dependencies and what's changed since the last snapshot. A transaction can use an old snapshot if it doesn't touch anything changed since the snapshot was taken. If it does you acquire a new snapshot (or switch to a newer existing one) and can swap it in safely, since you know they're the same for all data the xact has touched so far. I suspect that just replaces one expensive problem with one or more different expensive problems and is something that'd help a few workloads but hurt others. It's come up when people have asked why we take a new snapshot for every transaction but I haven't seen it explored much. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
