"Heikki Linnakangas" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-patches mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches