On 20 December 2012 00:43, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> The benefit of saying that only UPDATEs clean the block is that this >> penalises only the workload making the mess, rather than everybody >> cleaning up repeatedly over one messy guy. > > Right, but there are plenty of situations where having everybody clean > up after the messy guy is better than waiting around and hoping that > Mom (aka vacuum) will do it.
The problems I see are that cleaning on SELECT is too frequent, interferes with foreground performance and re-dirties data blocks too often. Waiting for Mom is configurable, since we can set parameters for autovacuum. But we can't turn off the cleaning by SELECTs, which makes the configurability of autovacuum somewhat moot. We could also contact the Cleaner instead. ISTM that if someone spots a block that could use cleanup, they mark the block as BM_PIN_COUNT_WAITER, but don't set pid. Then when they unpin the block they send a signal/queue work for a special cleaning process to come in and do the work now that nobody is waiting. Logic would allow VACUUMs to go past that by setting the pid. If we prioritised cleanup onto blocks that are already dirty we would minimise I/O. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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