Re: Process local hint bit cache - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Process local hint bit cache
Date
Msg-id AANLkTinc=VTwOf92S2ffGmTd-pDnOgLTsTxQQ4RQ+D5g@mail.gmail.com
Whole thread Raw
In response to Re: Process local hint bit cache  (Merlin Moncure <mmoncure@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] Date conversion using day of week
Next
From: Gurjeet Singh
Date:
Subject: Re: Problem with pg_upgrade?