On Wed, Mar 30, 2011 at 6:30 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Wed, Mar 30, 2011 at 2:35 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> >> btw I haven't forgotten your idea to move TransactionIdInProgress >> Down. I think this is a good idea, and will experiment with it pre and >> post cache. > > aside: > Moving TransactionIdInProgress below TransactionIdDidCommit can help > in once sense: TransactionIdDidCommit grabs the XidStatus but discards > the knowledge if the transaction is known aborted. If it is in fact > aborted you can immediately set the hint bits and punt. This should > save an awful lot of calls to TransactionIdInProgress when scanning > unhinted dead tuples.
Yeah, it might make sense to have a function that returns commit/abort/unsure, where unsure can only happen if the transaction ID follows RecentXmin. You might also want to rearrange things so that that function starts by checking the passed-in XID against cachedFetchXid so we don't lose the benefit of that one-element cache. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
