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






-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to