public inbox for [email protected]  

help / color / mirror / Atom feed

From: Imseih (AWS), Sami <[email protected]>
To: Nathan Bossart <[email protected]>
To: Robert Haas <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Joe Conway <[email protected]>
Cc: Michael Banck <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Frédéric Yhuel <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: New GUC autovacuum_max_threshold ?
Date: Wed, 8 May 2024 17:30:44 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <20240507211702.GA2720371@nathanxps13>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CA+TgmoZav6Mxv6qzPEZiAknzqdQ7Cq-oS1WJ6N-sPe5QyT2tiA@mail.gmail.com>
	<[email protected]>
	<CA+Tgmoa9FzNLNtD-PYptJP1ApV=a57RwqOVypb0gL5uLzLtCFQ@mail.gmail.com>
	<CAApHDvo8DWyt4CWhF=NPeRstz_78SteEuuNDfYO7cjp=7YTK4g@mail.gmail.com>
	<CA+TgmoaCQ_GCwn3V8uXc+60oSJivY6ouiAqe81Z3h1kT6zMMYQ@mail.gmail.com>
	<20240507211702.GA2720371@nathanxps13>

> This is about how I feel, too. In any case, I +1'd a higher default
> because I think we need to be pretty conservative with these changes, at
> least until we have a better prioritization strategy. While folks may opt
> to set this value super low, I think that's more likely to lead to some
> interesting secondary effects. If the default is high, hopefully these
> secondary effects will be minimized or avoided.


There is also an alternative of making this GUC -1 by default, which
means it has not effect and any value larger will be used in the threshold
calculation of autovacuunm. A user will have to be careful not to set it too low, 
but that is going to be a concern either way.


This idea maybe worth considering as it does not change the default
behavior of the autovac threshold calculation, and if a user has cases in 
which they have many tables with a few billion tuples that they wish to 
see autovacuumed more often, they now have a GUC to make 
that possible and potentially avoid per-table threshold configuration.


Also, I think coming up with a good default will be challenging,
and perhaps this idea is a good middle ground.


Regards,

Sami 

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: New GUC autovacuum_max_threshold ?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox