Re: Disable autovacuum guc? - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Disable autovacuum guc?
Date
Msg-id 76871e2a-1524-caf3-562a-45823b8949eb@commandprompt.com
Whole thread Raw
In response to Re: Disable autovacuum guc?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 10/19/2016 07:22 PM, Josh Berkus wrote:
> On 10/19/2016 06:27 PM, Joshua D. Drake wrote:
>> Hello,
>>
>> After all these years, we are still regularly running into people who
>> say, "performance was bad so we disabled autovacuum". I am not talking
>> about once in a while, it is often. I would like us to consider removing
>> the autovacuum option. Here are a few reasons:
>>
>> 1. It does not hurt anyone
>> 2. It removes a foot gun
>> 3. Autovacuum is *not* optional, we shouldn't let it be
>> 4. People could still disable it at the table level for those tables
>> that do fall into the small window of, no maintenance is o.k.
>> 5. People would still have the ability to decrease the max_workers to 1
>> (although I could argue about that too).
>
> People who run data warehouses where all of the data comes in as batch
> loads regularly disable autovacuum, and should do so.  For the DW/batch
> load use-case, it makes far more sense to do batch loads interspersed
> with ANALYZEs and VACUUMS of loaded/updated tables.

Hrm, true although that is by far a minority of our users. What if we 
made it so we disabled the autovacuum guc but made it so you could 
disable autovacuum per database (ALTER DATABASE SET or something such 
thing?).

Sincerely,

JD


-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Remove autovacuum GUC?
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: two slab-like memory allocators