Re: Process local hint bit cache
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Greg Stark <gsstark@mit.edu>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-03-31T16:38:59Z
Lists: pgsql-hackers
On Wed, Mar 30, 2011 at 6:30 PM, Merlin Moncure <mmoncure@gmail.com> wrote: > On Wed, Mar 30, 2011 at 2:35 PM, Merlin Moncure <mmoncure@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