From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hint bit i/o reduction |
Date: | 2012-06-13 13:19:40 |
Message-ID: | CAHyXU0wiBFVACDKji-33YJmWW7dz9N4hprTgM5UwSWOM3LfhiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 13, 2012 at 3:57 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Honza Horak | 2012-06-13 13:25:10 | Re: Ability to listen on two unix sockets |
Previous Message | Honza Horak | 2012-06-13 13:14:53 | Re: Ability to listen on two unix sockets |