From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HOT is applied |
Date: | 2007-09-21 17:25:16 |
Message-ID: | 10821.1190395516@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-09-21 17:41:08 | Re: like/ilike improvements |
Previous Message | Heikki Linnakangas | 2007-09-21 17:17:11 | Re: HOT is applied |