Re: Turning off HOT/Cleanup sometimes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Turning off HOT/Cleanup sometimes
Date: 2015-04-20 22:13:38
Message-ID: 20150420221338.GY4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
> On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > This seems simple to implement: keep two counters, where the second one
> > is pages we skipped cleanup in. Once that counter hits SOME_MAX_VALUE,
> > reset the first counter so that further 5 pages will get HOT pruned. 5%
> > seems a bit high though. (In Simon's design, SOME_MAX_VALUE is
> > essentially +infinity.)
>
> This would tend to dirty non-sequential heap pages --- it seems best to
> just clean as many as we are supposed to, then skip the rest, so we can
> write sequential dirty pages to storage.

Keep in mind there's a disconnect between dirtying a page and writing it
to storage. A page could remain dirty for a long time in the buffer
cache. This writing of sequential pages would occur at checkpoint time
only, which seems the wrong thing to optimize. If some other process
needs to evict pages to make room to read some other page in, surely
it's going to try one page at a time, not write "many sequential dirty
pages."

--
Á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 Peter Geoghegan 2015-04-20 22:49:21 Re: parallel mode and parallel contexts
Previous Message Jim Nasby 2015-04-20 22:00:17 Re: Freeze avoidance of very large table.