Simon Riggs wrote:
We currently have a single item cache of the last checked TransactionId,
which optimises the call to TransactionIdDidCommit() during
HeapTupleSatisfiesMVCC() and partners.
Before we call TransactionIdDidCommit() we always call
TransactionIdIsInProgress().
TransactionIdIsInProgress() doesn't check the single item cache, so even
if we have just checked for this xid, we will check it again. Since this
function takes ProcArrayLock and may be called while holding other locks
it will improve scalability if we can skip the call, for the cost of an
integer comparison.
Seems plausible. Have you done any performance testing?
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.
To matter from scalability point of view, there would need to be a lot
of concurrent activity that compete for the lock. Can you formulate a
test case for that?
Following patch implements fastpath in TransactionIdIsInProgress() to
utilise single item cache.
Hmm. The pattern in tqual.c is:
if (!TransactionIdIsInProgress(xvac))
{
if (TransactionIdDidCommit(xvac))
{
/* committed */
}
else
{
/* aborted */
}
}
else
{
/* in-progress */
}
We could do this instead:
if (TransactionIdDidCommit(xvac))
{
/* committed */
}
else if (!TransactionIdIsInProgress(xvac))
{
if (TransactionIdDidCommit(xvac))
{
/* committed */
}
else
{
/* aborted */
}
}
else
{
/* in-progress */
}
(hopefully there would be a way to macroize that or something to avoid
bloating the code any more.)
For committed transactions, this would save the
TransactionIdIsInProgress call completely, whether or not it's in the
one-item cache. The tradeoff is that we would have to call
TransactionIdDidCommit twice for aborted transactions.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
