Bruce Momjian <bruce@momjian.us> writes:
> Simon Riggs wrote:
>> How much does it cost to optimise for this case?
> Zero cost. It involves just tracking if there are any old snapshots,
I will be fascinated to hear how you define that as zero cost. It might
be relatively low, but it's not zero, and for many simple cases (eg,
all single-statement transactions) the benefit will indeed be zero.
We need some serious consideration of the costs and benefits, not airy
dismissals.
I had originally thought that we could avoid CopySnapshot copying,
which might buy back more than enough to cover the cost of tracking
reference counts ... but in a quick look yesterday it seemed that the
high-use code paths would still need a copy, because they are always
copying off the static variables filled by GetTransactionSnapshot.
Changing that would come with a tremendous memory penalty, or else
a time penalty to scan the ProcArray twice to see how big the arrays
need to be.
[ thinks a bit... ] The other way we might possibly tackle that is
to avoid copying by the expedient of just using those static snapshot
variables in-place. SerializableSnapshot surely need never be copied
since it remains unchanged till end of xact, and no use of the snap
will survive longer than that. In simple cases LatestSnapshot is not
overwritten until the prior value is no longer needed, either. If
we could arrange to copy it only when setting up a cursor, or other
long-lived usage, we'd be ahead of the game. But I'd certainly want
a management layer in there to ensure that we don't overwrite a value
that *is* still in use, and offhand I'm not sure what that layer would
need to look like. Possibly some sort of double indirection so that
callers would have a Snapshot pointer that remained valid after we'd
copied off arrays that need to be updated? We already do have double
indirection in the form of the Snapshot and xip[] pointers ... maybe
attach refcounts to the xip arrays not the Snapshots per se?
regards, tom lane