Re: hint bit i/o reduction - Mailing list pgsql-hackers

> 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

You are right, adding in above path should not impact any performance and
moreover all the checks and assignment you are purposing is backend local so
no contention also.

Just an observation that in some cases, it will just do only point-1 or
point-1 and point-2.
For example
1. xmin is committed and hint bit is already set.
2. xmax is hint bit is not set, and its still not visible to current
transaction.
In this case it will just do point-1 and point-2.


-----Original Message-----
From: Merlin Moncure [mailto:mmoncure@gmail.com]
Sent: Wednesday, June 13, 2012 8:36 PM
To: Amit Kapila
Cc: PostgreSQL-development
Subject: Re: [HACKERS] hint bit i/o reduction

On Wed, Jun 13, 2012 at 9:02 AM, Amit Kapila <amit.kapila@huawei.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