Re: Process local hint bit cache
От | Robert Haas |
---|---|
Тема | Re: Process local hint bit cache |
Дата | |
Msg-id | AANLkTinc=VTwOf92S2ffGmTd-pDnOgLTsTxQQ4RQ+D5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Process local hint bit cache (Merlin Moncure <mmoncure@gmail.com>) |
Список | 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 по дате отправления: