Re: eXtensible Transaction Manager API

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: eXtensible Transaction Manager API
Дата
Msg-id CAMsr+YFdzG-=rARNJJC_vYGAY1mH5G6R78EFmbjdfuTN0VKwNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: eXtensible Transaction Manager API  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 4 December 2015 at 06:41, Robert Haas <robertmhaas@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Remaining 9.5 open items