On Thu, Nov 15, 2012 at 10:14 PM, Pavan Deolasee <pavan.deola...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
