> 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.
However I think if you have already tested the scenario for same then there
should not be any problem.
-----Original Message-----
From: Merlin Moncure [mailto:mmoncure@gmail.com]
Sent: Wednesday, June 13, 2012 6:50 PM
To: Amit Kapila
Cc: PostgreSQL-development
Subject: Re: [HACKERS] hint bit i/o reduction
On Wed, Jun 13, 2012 at 3:57 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
>> 1) Keep track # times the last transaction id was repeatedly seen in
>> tqual.c (resetting as soon as a new xid was touched. We can do this
>> just for xmin, or separately for both xmin and xmax.
>
> Will this be done when we see a new xid duricg scan of tuple, if yes then
> Won't this logic impact incase there are very few records per transaction
in
> database.
> As in that case the new optimization won't help much, but it adds the new
> instructions.
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.
>> We can also try to be smart and disable
>> the 'avoid setting the hint bit' logic if the page is already dirty.
>
> Whats the benefit for not setting hint bit for a already dirty page.
Nothing -- we are disabling the '*avoid* setting the hint bit' logic
(double negative there). In other words we would be disabling the
setting of hint bits if we see the same transaction many times in a
row, but only if the page isn't dirty.
merlin