"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

> 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 (pgsql-patches@postgresql.org)
To make changes to your subscription:

Reply via email to