Re: Proposal for CSN based snapshots - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Proposal for CSN based snapshots
Date
Msg-id 1409075935.2335.358.camel@jeff-desktop
Whole thread Raw
In response to Re: Proposal for CSN based snapshots  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Switch pg_basebackup to use -X stream instead of -X fetch by default?
Next
From: Greg Stark
Date:
Subject: Re: Proposal for CSN based snapshots