Re: Turning off HOT/Cleanup sometimes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 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-16 20:27:42
Message-ID: 20150416202742.GN4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund wrote:
> On 2015-04-16 10:20:20 -0300, Alvaro Herrera wrote:
> > I think you're failing to consider that in the patch there is a
> > distinction between read-only page accesses and page updates. During a
> > page update, HOT cleanup is always done even with the patch, so there
> > won't be any additional bloat that would not be there without the
> > patch.
>
> That's not really true (and my benchmark upthread proves it). The fact
> that hot pruning only happens when we can get a cleanup lock means that
> we can end up with more pages that are full, if we prune on select less
> often. Especially if SELECTs are more frequent than write accesses -
> pretty darn common - the likelihood of SELECTs getting the lock is
> correspondingly higher.

Interesting point. Of course, this code should count HOT cleanups
against the total limit when they are effectively carried out, and
ignore those that are skipped because of inability to acquire the
cleanup lock. Not sure whether the submitted code does that.

Can we keep stats on how many pages we don't clean in the updating
process due to failure to acquire cleanup lock? My intuition says that
it should be similar to the number of backends running concurrently,
but that might be wrong.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-04-16 21:43:33 Re: inherit support for foreign tables
Previous Message David G. Johnston 2015-04-16 20:18:52 Re: FILTER/WITHIN GROUP vs. expressions; is a HINT possible here?