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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
