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

From Nathan Bossart
Subject Re: New GUC autovacuum_max_threshold ?
Date
Msg-id Zy5N-M2jPIYzPdku@nathan
Whole thread Raw
In response to Re: New GUC autovacuum_max_threshold ?  (wenhui qiu <qiuwenhuifx@gmail.com>)
List pgsql-hackers
On Wed, Nov 06, 2024 at 08:51:07PM +0800, wenhui qiu wrote:
>> Thank you. FWIW, I would prefer a sub-linear growth, so maybe something
>> like this
> 
>>   vacthresh = Min(vac_base_thresh + vac_scale_factor * reltuples,
>>   vac_base_thresh + vac_scale_factor * pow(reltuples, 0.7) * 100);
> 
>>   This would give :
> 
>>   * 386M (instead of 5.1 billion currently) for a 25.6 billion tuples
> table ;
>>   * 77M for a 2.56 billion tuples table (Robert's example) ;
>>   * 15M (instead of 51M currently) for a 256M tuples table ;
>>   * 3M (instead of 5M currently) for a 25.6M tuples table.
>> The other advantage is that you don't need another GUC.
> Argee ,We just need to change the calculation formula,But I prefer this
> formula because it calculates a smoother value.
> 
> vacthresh =  (float4) fmin(vac_base_thresh + vac_scale_factor *
> reltuples,vac_base_thresh
> + vac_scale_factor * log2(reltuples) * 10000);
> or
> vacthresh = (float4) fmin(vac_base_thresh + (vac_scale_factor * reltuples)
> , sqrt(1000.0 * reltuples));

I apologize for the curt response, but I don't understand how we could
decide which of these three complicated formulas to use, let alone how we
could expect users to reason about the behavior.

-- 
nathan



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Use __attribute__((target(sse4.2))) for SSE42 CRC32C
Next
From: "Devulapalli, Raghuveer"
Date:
Subject: RE: Use __attribute__((target(sse4.2))) for SSE42 CRC32C