Simon Riggs wrote:
> On 15 April 2015 at 09:10, Andres Freund <andres@anarazel.de> wrote:
> > I don't really see the downside to this suggestion.
>
> The suggestion makes things better than they are now but is still less
> than I have proposed.
>
> If what you both mean is "IMHO this is an acceptable compromise", I
> can accept it also, at this point in the CF.
Let me see if I understand things.
What we have now is: when reading a page, we also HOT-clean it. This
runs HOT-cleanup a large number of times, and causes many pages to
become dirty.
Your patch is "when reading a page, HOT-clean it, but only 5 times in
each scan". This runs HOT-cleanup at most 5 times, and causes at most 5
pages to become dirty.
Robert's proposal is "when reading a page, if dirty HOT-clean it; if not
dirty, also HOT-clean it but only 5 times in each scan". This runs
HOT-cleanup some number of times (as many as there are dirty), and
causes at most 5 pages to become dirty.
Am I right in thinking that HOT-clean in a dirty page is something that
runs completely within CPU cache? If so, it would be damn fast and
would have benefits for future readers, for very little cost.
Dirtying a page is very different; if buffer reads are common, the
system is later bogged down trying to find clean pages to read uncached
buffers (including the read-only scan itself, so it becomes slower.)
If I have understood things correctly, then I stand behind Robert's
suggestion.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services