On Thu, Nov 15, 2012 at 10:14 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> Another approach could be to set those additional bits, but don't dirty the
> page. So if the page is already dirty or gets dirty later on before its
> eviction, those hint bits will get recorded. We can also try some other
> variants like: set the bits and dirty the page if the XID is beyond the
> horizon that CLOG buffers can track. A very old XID will most likely cause a
> CLOG page read later on.
>
> I forgot if we have a way to differentiate between critical and non-critical
> dirtiness of a page. If we don't, that might be another worthwhile thing to
> try and test. Setting hint bits is a non-critical operation. So such a dirty
> page may be discarded if the system is under pressure.
>
> Well, all of the above may have been discussed and rejected in the past.
> What we need is a thorough benchmarking to know what is better in which
> situation.
Yeah: all previous ideas attempts manage hint bits through trade-offs
have failed because of general nervousness about who loses. The
unlucky guy who has high transaction rates that suddenly has a big
increase in clog activity is in for a world of hurt.
Also, AIUI 'set but don't dirty' strategies are less effective if/when
checksums are implemented as currently proposed. Previously hint bit
mitigation was all about saving some i/o. Now, everything is getting
rammed through the WAL lock.
merlin
