"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Yeah. I played with this a bit more, and came up with a couple of other
> micro-optimizations:
> 1. Instead of pallocing and pfreeing a new array in
> TransactionIdIsInProgress, we could just malloc the array once and reuse
> it. That palloc/pfree alone was consuming around 8% of CPU time in the
> test case.
Good idea --- not only faster, but we can get rid of all the goto's and
the "locked" flag, if we're willing to have a couple more LWLockRelease
calls here. I'll incorporate this in the patch I'm working up.
> We've already checked that the xmin is our own transaction id, so we
> check if the xmax is an aborted subtransaction of our own transaction. A
> TransactionIdDidAbort call seems like an awfully expensive way to check
> that. We could call TransactionIdIsCurrentTransactionId instead, which
> doesn't need to access any shared memory structures (but might be
> expensive if you have a lot of active subxacts, as you pointed out).
I like that idea too ...
> 3. One more general alternative to the little patch I sent earlier would
> be to build an array of in-progress-xids in TransactionIdInProgress,
> like we do in GetSnapshotData, and use that for the in-progress checks
> in HeapTupleSatisfiesVacuum. That should work, if we build the cached
> array when we lock the page for pruning, and use it until we unlock.
This seems like it uglifies a whole lot of APIs, though, for what's
probably not going to be a lot of gain.
regards, tom lane