Re: Should we increase the default vacuum_cost_limit? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should we increase the default vacuum_cost_limit?
Date
Msg-id CA+TgmoZ0W53bGs=omiF0NsOK2Zq+cDHggTq1brjCRwGwZrF-Rg@mail.gmail.com
Whole thread Raw
In response to Re: Should we increase the default vacuum_cost_limit?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Tue, Mar 5, 2019 at 7:53 AM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> But on the other hand it feels a bit weird that we increase this one
> value and leave all the other (also very conservative) defaults alone.

Are you talking about vacuum-related defaults or defaults in general?
In 2014, we increased the defaults for work_mem and
maintenance_work_mem by 4x and the default for effective_cache_size by
32x; in 2012, we increased the default for shared_buffers from by 4x.
It's possible some of those parameters should be further increased at
some point, but deciding not to increase any of them until we can
increase all of them is tantamount to giving up on changing anything
at all.  I think it's OK to be conservative by default, but we should
increase parameters where we know that the default is likely to be too
conservative for 99% of users.  My only question about this change is
whether to go for a lesser multiple (e.g. 4x) rather than the proposed
10x.  But I think even if 10x turns out to be too much for a few more
people than we'd like, we're still going to be better off increasing
it and having some people have to turn it back down again than leaving
it the way it is and having users regularly suffer vacuum-starvation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Andy Fan
Date:
Subject: any plan to support shared servers like Oracle in PG?