Re: hint bit i/o reduction

On Wed, Jun 13, 2012 at 9:02 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> Yes, but only in the unhinted case -- in oltp workloads tuples get
>> hinted fairly quickly so I doubt this would be a huge impact.  Hinted
>> scans will work exactly as they do now.  In the unhinted case for OLTP
>> a  few tests are added but that's noise compared to the other stuff
>> going on.
>
> I believe the design you have purposed is for the unhinted cases only, means
> if the tuple has already hint set then it will not go to new logic. Is that
> right?
>
> In unhinted cases, there can be 2 ways hint bit can be set
> 1. It gets the transaction status from Clog memory buffers
> 2. It needs to do I/O to get the transaction status from Clog.
>
> So, I think it will add overhead in case-1 where the processing is fast, but
> now we will add some new instructions to it.

yeah -- but you still have to call:
*) TransactionIdIsCurrentTransactionId(), which adds a couple of tests
(and a bsearch in the presence of subtransactions)
*) TransactionIdIsInProgress() which adds a few tests and a out of
line call in the typical case
*) TransactionIdDidCommit() which adds a few tests and two out of line
calls in the typical case
and, while setting the hint it:
*) Several more tests plus:
*) TransactionIdGetCommitLSN() another out of line call and a test
*) XLogNeedsFlush() two more out of line calls plus a few tests
*) SetBufferCommitInfoNeedsSave out of line call, several more tests

adding a few instructions to the above probably won't be measurable
(naturally it would be tested to confirm that).

merlin