Re: Process local hint bit cache
От | Merlin Moncure |
---|---|
Тема | Re: Process local hint bit cache |
Дата | |
Msg-id | AANLkTi=4m0To4uA3eaqfTbQ+ydk9vDksy9-UPVVJ0f=U@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Process local hint bit cache (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Process local hint bit cache
Re: Process local hint bit cache |
Список | pgsql-hackers |
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. otoh, checking commit status first can burn you if you are repeatedly tuples that are in transaction, especially your own. Probably this could be mitigated by splitting TransactionIdIsInProgress so that you can do just the local checks and not shared memory, so that you could: 1. is this transaction mine? (if so, we are done) 2. get xid status if commit/abort done 3. do ProcArray portions of TransactionIdIsInProgress merlin
В списке pgsql-hackers по дате отправления: