Re: Make HeapTupleSatisfiesMVCC more concurrent

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Make HeapTupleSatisfiesMVCC more concurrent
Дата
Msg-id CANP8+j+jytogNb8+j2E1OEQNpxEC5W8iR+4XtLgSPxLh=jiHKA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Make HeapTupleSatisfiesMVCC more concurrent  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 19 August 2015 at 16:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> I'm not sure about it, but it might be worthwhile to add a
>> TransactionIdIsKnownCompleted() check before the more expensive parts of
>> XidInMVCCSnapshot(). Neither the array search nor, much more so, the
>> subtrans lookups are free.

> Hmmm... the comment for TransactionIdIsKnownCompleted says it's to
> short-circuit calls of TransactionIdIsInProgress, which we wouldn't be
> doing anymore.  Maybe it's useful anyway but I'm not convinced.

After further thought, the right way to implement the equivalent
optimization would be to add a couple of fields to struct Snapshot that
would cache the xid last checked against that snapshot and the outcome of
that check; this would be independent of TransactionIdIsKnownCompleted.
There would be no need to use that cache for xids below xmin or above
xmax, which would improve its chance of being applicable to in-doubt xids.

Not entirely sure it's worth doing, but if someone wants to do the
legwork, this would be an independent optimization possibility.

This is what I suggested upthread.  It's not a massive gain, but its cheap and a straightforward patch.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Proposal: Implement failover on libpq connect level.
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: allowing wal_level change at run time