Re: hint bit i/o reduction
От | Merlin Moncure |
---|---|
Тема | Re: hint bit i/o reduction |
Дата | |
Msg-id | CAHyXU0wiBFVACDKji-33YJmWW7dz9N4hprTgM5UwSWOM3LfhiQ@mail.gmail.com обсуждение исходный текст |
Ответ на | hint bit i/o reduction (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: hint bit i/o reduction
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: