Re: New GUC autovacuum_max_threshold ? - Mailing list pgsql-hackers
| From | wenhui qiu |
|---|---|
| Subject | Re: New GUC autovacuum_max_threshold ? |
| Date | |
| Msg-id | CAGjGUAJuT0qfMNS6ipNa9XPWHjW7BhBXW2qgC+a6yOoBNmOuSg@mail.gmail.com Whole thread Raw |
| In response to | Re: New GUC autovacuum_max_threshold ? (wenhui qiu <qiuwenhuifx@gmail.com>) |
| List | pgsql-hackers |
HI Nathan
> I had the opportunity to bring this patch up for discussion at the
> developer meeting at FOSDEM PGDay last week [0]. We discussed a subset
> of the topics folks have already written about in this thread, and AFAICT
> there was general approval among the attendees for proceeding with the
> "hard cap" approach due to its user-friendliness. Given that, I am
> planning to commit the attached patch in the near future (although I may
> I had the opportunity to bring this patch up for discussion at the
> developer meeting at FOSDEM PGDay last week [0]. We discussed a subset
> of the topics folks have already written about in this thread, and AFAICT
> there was general approval among the attendees for proceeding with the
> "hard cap" approach due to its user-friendliness. Given that, I am
> planning to commit the attached patch in the near future (although I may
> fiddle with the commit message a bit more).
Thanks for your work on this ,that is good news.Any method that solves the issue of vacuum being triggered by large tables is a good method.When more comprehensive vacuum statistics become available in the future, we can improve the calculation method then.
On Tue, Feb 4, 2025 at 3:51 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
I had the opportunity to bring this patch up for discussion at the
developer meeting at FOSDEM PGDay last week [0]. We discussed a subset
of the topics folks have already written about in this thread, and AFAICT
there was general approval among the attendees for proceeding with the
"hard cap" approach due to its user-friendliness. Given that, I am
planning to commit the attached patch in the near future (although I may
fiddle with the commit message a bit more).
On Tue, Jan 14, 2025 at 11:35:17PM +0300, Alena Rybakina wrote:
> #autovacuum_vacuum_max_threshold = 100000000 # max number of row updates
> # before vacuum; -1 disables max
> # threshold
>
> I think instead of "# threshold" should be "#vacuum"?
That would more closely match the description of
autovacuum_vacuum_insert_threshold, which refers to "insert vacuums," but I
felt it would be weird to refer to "max vacuums." IMHO it is clearer to
say that -1 disables the maximum threshold here.
> There is a typo:
>
> * if (threshold > vac_max_thresh)
> * threshold = vac_max_thres; - here
Fixed.
> I think you should add more information to the description of the
> Relations_needs_vacanalyze function: what is vac_max_thresh and how is it
> calculated. It is not clear what the below condition means.
>
> /* -1 is used to disable max threshold */
> vac_max_thresh= (relopts&& relopts->vacuum_max_threshold>= -1)
> ? relopts->vacuum_max_threshold
> : autovacuum_vac_max_thresh;
I looked at the commentary for this function and felt that the comments for
this new parameter are in line with the comments for all the adjacent
parameters. There may be an opportunity to improve this commentary, but
IMHO that would be better handled in a separate patch that improved it for
all these parameters.
[0] https://2025.fosdempgday.org/devmeeting
--
nathan
pgsql-hackers by date: