"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> I presume the case where this would help would be when you populate a
> large table, with COPY for example, and the run a seq scan on it. As all
> rows in the table have the same xmin, you keep testing for the same XID
> over and over again.
Yeah, that's the reasoning for having the single-element cache in
transam.c in the first place. Mass updates and mass deletes would
also result in a lot of probes of the same XID on the next examination
of the table.
Simon's idea looks sane, although "TransactionIdIsKnownNotInProgress"
seems a kinda weird name ... it feels like a double negative to me,
although strictly speaking it's not. Maybe instead
TransactionIdIsKnownCompleted?
> To matter from scalability point of view, there would need to be a lot
> of concurrent activity that compete for the lock.
I think it's probably useful just from a cycles-saved point of view.
And we do know that ProcArrayLock is a hot spot.
> Hmm. The pattern in tqual.c is:
> ...
> We could do this instead:
> ...
I dislike this alternative because tqual.c is mind-bendingly complex
already. Simon's approach hides the issue somewhere else where there
aren't so many code paths to keep straight.
regards, tom lane
