There has recently been considerable discussion around auto-tuning. Throughout the course of this discussion, I raised the idea of creating a new GUC to separately control autovacuum's usage of maintenance_work_mem [1], explaining the rationale in some detail [2]. At the time Magnus seemed to think this a good idea [3].
Attached simple patch adds a new GUC, autovacuum_work_mem, which when set to a value other than -1 (the default) is preferred by autovacuum over maintenance_work_mem. All other usage of VACUUM is unaffected. I won't repeat the rationale for the patch here. Appropriate documentation changes are included. I don't think it's a problem that autovacuum_work_mem is kind of similar to vacuum_mem in name. maintenance_work_mem was last spelt vacuum_mem about 10 years ago. Enough time has passed that I think it very unlikely that someone might conflate the two. I have decided to have the default value of -1 carry, and not have it automatically take the same value as maintenance_work_mem, because doing so could create the impression that it needs to be set explicitly, which of course it does not - this is not the same situation as exists for wal_buffers. We just check if its set when going to VACUUM, if VACUUM is requested from a worker process. It seemed neater to me to create a new flag, so that in principle any vacuum() code path can request autovacuum_work_mem, rather than having lazyvacuum.c code call IsAutoVacuumWorkerProcess() for the same purpose. To date, that's only been done within vacuumlazy.c for things like logging. [1] http://www.postgresql.org/message-id/cam3swztr1uu+7kr1zougwcjriw9nvbqdjqydmrwypevdfi4...@mail.gmail.com [2] http://www.postgresql.org/message-id/cam3swztyod0ycla-4nrb4s8-ugjyr514aey+8o6vjqwvbzs...@mail.gmail.com [3] http://www.postgresql.org/message-id/CABUevEzVrd36yeFzYBzad0=r09eqRqNoMwX8r=urikg9drf...@mail.gmail.com -- Peter Geoghegan
autovacuum_work_mem.v1.2013_10_19.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
