From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: TransactionIdIsInProgress() cache |
Date: | 2008-03-11 17:15:07 |
Message-ID: | 26201.1205255707@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-03-11 17:18:56 | Re: [PATCHES] Fix for large file support (nonsegment mode support) |
Previous Message | Zdenek Kotala | 2008-03-11 17:07:21 | Re: Remove FATAL from pg_lzdecompress |