Re: autovacuum_work_mem - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: autovacuum_work_mem
Date
Msg-id CAM3SWZR=3uuov_oHEpXU8X-08W0LK5_C6oeXv5RoTRnfHAnCmA@mail.gmail.com
Whole thread Raw
In response to Re: autovacuum_work_mem  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: autovacuum_work_mem
List pgsql-hackers
On Wed, Dec 11, 2013 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> But nobody has given a sensible answer to my questions, other than to
> roll out the same general points again. In practice, its a knob that
> does not do very much of use for us. At best it is addressing the
> symptoms, not the cause. IMHO.

It's just a usability feature. It lessens the intellectual overhead of
managing maintenance_work_mem. I understand that it isn't very
impressive from a technical point of view. However, in many
environments, it actually will make a significant difference, because
non-autovacuum maintenance operations are very rare compared to
autovacuum workers vacuuming, and therefore I can now afford to be
much less conservative in setting maintenance_work_mem globally on
each of 8 Postgres instances hosted on a single box. These are
precisely the kinds of Postgres instances where users are very
unlikely to have heard of maintenance_work_mem at all. These users are
not even using an admin tool in many cases, preferring to rely on ORM
migrations.  Having said that, it's also something I'll find useful on
a day to day basis, because it's a chore to set maintenace_work_mem
manually, and sometimes I forget to do so, particularly when under
pressure to relieve a production performance issues on a random
customer's database.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: 9.3 reference constraint regression
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Time-Delayed Standbys