Re: New GUC autovacuum_max_threshold ?

From: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Michael Banck <mbanck(at)gmx(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: New GUC autovacuum_max_threshold ?
Date: 2024-11-10 11:25:45
Message-ID: CAGjGUA+jLAA+E-2NZ7fp9NJTu8xS+zms8vduO_o3eU-ZoWGQ6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nathan Bossart
> AFAICT the main advantage of these formulas is that you don't need another
> GUC, but they also makes the existing ones more difficult to configure.
> Plus, there's no way to go back to the existing behavior.
There is indeed this problem,But I think this formula should not be a
linear relationship in the first place,SQL Server was realized and
optimized eight years ago. I think we can definitely draw on the experience
of SQL Server.Maybe many people are worried that frequent vacuum will
affect io performance, but we can learn from the experience of SQL Server
in vacuum analysis .

Nathan Bossart <nathandbossart(at)gmail(dot)com> 于2024年11月9日周六 23:59写道:

> On Sat, Nov 09, 2024 at 10:08:51PM +0800, wenhui qiu wrote:
> > Sorry ,I forgot to explain the reason in my last email,In fact, I
> > submitted the patch to the community,(frederic(dot)yhuel(at)dalibo(dot)com) told me
> > there has a same idea ,so ,
> > Let me explain those two formulas here,about ( vacthresh =
> (float4)
> > fmin(vac_base_thresh + (vac_scale_factor * reltuples), sqrt(1000.0 *
> > reltuples)); A few days ago, I was looking at the sql server
> > documentation and found that sql server has optimized the algorithm
> related
> > to updating statistics in the 2016 ,version,I think we can also learn
> from
> > the implementation method of sql server to optimize the problem of
> > automatic vacuum triggered by large tables,The Document link(
> >
> https://learn.microsoft.com/en-us/sql/relational-databases/statistics/statistics?view=sql-server-ver16
> > ),about ( vacthresh = (float4) fmin(vac_base_thresh + vac_scale_factor *
> > reltuples,vac_base_thresh+ vac_scale_factor * log2(reltuples) *
> 10000);)I
> > came to the conclusion by trying to draw a function graph,I personally
> > think it is a smooth formula
>
> AFAICT the main advantage of these formulas is that you don't need another
> GUC, but they also makes the existing ones more difficult to configure.
> Plus, there's no way to go back to the existing behavior.
>
> --
> nathan
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2024-11-10 12:43:21 Re: Add missing tab completion for ALTER TABLE ADD COLUMN IF NOT EXISTS
Previous Message Bennie Swart 2024-11-10 11:11:51 Re: Join removal and attr_needed cleanup