Re: Proposal for CSN based snapshots

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Proposal for CSN based snapshots
Дата
Msg-id 1409075935.2335.358.camel@jeff-desktop
обсуждение исходный текст
Ответ на Re: Proposal for CSN based snapshots  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
> My current thinking is that access to the csnlog will need to be made 
> faster. Currently, it's just another SLRU, but I'm sure we can do better 
> than that. Or add a backend-private cache on top of it; that might 
> already alleviate it enough..

Aren't those the same ideas that have been proposed for eliminating hint
bits?

If this patch makes taking snapshots much faster, then perhaps it's
enough incentive to follow through on one of those ideas. I am certainly
open to removing hint bits (which was probably clear from earlier
discussions) if there are significant wins elsewhere and the penalty is
not too great.

To continue the discussion on this patch, let's assume that we make
TransactionIdGetCommitLSN sufficiently fast. If that's the case, can't
we make HeapTupleSatisfiesMVCC look more like:
 LsnMin = TransactionIdGetCommitLSN(xmin); if (!COMMITLSN_IS_COMMITTED(LsnMin))    LsnMin = BIG_LSN;
 LsnMin = TransactionIdGetCommitLSN(xmin); if (!COMMITLSN_IS_COMMITTED(LsnMin))    LsnMin = BIG_LSN;
 return (snapshot->snapshotlsn >= LsnMin &&         snapshot->snapshotlsn <  LsnMax);

There would need to be some handling for locked tuples, or tuples
related to the current transaction, of course. But I still think it
would turn out simpler; perhaps by enough to save a few cycles.

Regards,Jeff Davis







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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Switch pg_basebackup to use -X stream instead of -X fetch by default?
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Proposal for CSN based snapshots