On Wed, Jun 13, 2012 at 9:02 AM, Amit Kapila <amit.kap...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
