Re: New GUC autovacuum_max_threshold ? - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: New GUC autovacuum_max_threshold ?
Date
Msg-id Zy-G7u43r1siVkQ6@nathan
Whole thread Raw
In response to Re: New GUC autovacuum_max_threshold ?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: New GUC autovacuum_max_threshold ?
Re: New GUC autovacuum_max_threshold ?
List pgsql-hackers
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.yhuel@dalibo.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



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: New "single" COPY format
Next
From: Sergey Prokhorenko
Date:
Subject: Re: UUID v7