Re: TransactionIdIsInProgress() cache - Mailing list pgsql-patches

From Tom Lane
Subject Re: TransactionIdIsInProgress() cache
Date
Msg-id 2311.1205262669@sss.pgh.pa.us
Whole thread Raw
In response to Re: TransactionIdIsInProgress() cache  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: TransactionIdIsInProgress() cache
List pgsql-patches
Simon Riggs <simon@2ndquadrant.com> writes:
> No, I haven't done any formal performance testing on it. It seemed an
> obvious hole that everyone would agree we should avoid, since we can do
> it so cheaply: one integer comparison against scanning the whole
> procarray and taking an LWlock.

[ after reading the patch a bit closer... ]  Actually, it's not as
obvious as all that.  TransactionIdIsInProgress already falls out before
the proposed test for any XID < RecentXmin, which means that in reality
it's fairly probable that the target XID is running.  So while this test
may not cost much, it's not clear that it really buys much either.

I'm going to go ahead and apply it, but it'd be good if someone would
verify that it at least doesn't cost anything on some real benchmarks.

BTW, I think we should put it in front of, not after, the
TransactionIdIsCurrentTransactionId test, since as was just being
discussed that could have nontrivial execution time.  (I'll go look at
Heikki's improvement on that next, but it'll still be not-free if
there's lots of subtransactions.)

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem
Next
From: Tom Lane
Date:
Subject: Re: TransactionIdIsInProgress() cache