Re: Turning off HOT/Cleanup sometimes - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Turning off HOT/Cleanup sometimes
Date
Msg-id 20150416132020.GL4369@alvh.no-ip.org
Whole thread Raw
In response to Re: Turning off HOT/Cleanup sometimes  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: Turning off HOT/Cleanup sometimes
Re: Turning off HOT/Cleanup sometimes
List pgsql-hackers
Pavan Deolasee wrote:
> On Thu, Apr 16, 2015 at 2:47 PM, Greg Stark <stark@mit.edu> wrote:

> > From a holistic point of view the question is how many times is a given
> > hit chain going to need to be followed before it's pruned. Or to put it
> > another way, how expensive is creating a hot chain. Does it cause a single
> > prune? a fixed number of chain readers followed by a prune? Does the amount
> > of work depend on the workload or is it consistent?
> 
> IMO the size or traversal of the HOT chain is not that expensive compared
> to the cost of either pruning too frequently, which generates WAL as well
> as makes buffers dirty. OTOH cost of less frequent pruning could also be
> very high. It can cause severe table bloat which may just stay for a very
> long time. Even if dead space is recovered within a page, truncating a
> bloated heap is not always possible.

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.
It's only the read-only accesses to the patch that skip the HOT pruning.

Of course, as Greg says there will be some additional scans of the HOT
chain by read-only processes.

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and WAL archive interactions
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: initdb -S and tablespaces