Re: Turning off HOT/Cleanup sometimes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2015-04-15 14:44:21
Message-ID: 20150415144421.GB4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On 15 April 2015 at 09:10, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-04-15 14:51:30 Re: [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/
Previous Message Heikki Linnakangas 2015-04-15 14:30:41 Re: WAL format changes break the suppression of do-nothing checkpoints.