Re: New GUC autovacuum_max_threshold ?
wenhui qiu <qiuwenhuifx@gmail.com>
From: wenhui qiu <qiuwenhuifx@gmail.com>
To: Frédéric Yhuel <frederic.yhuel@dalibo.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Robert Haas <robertmhaas@gmail.com>, "Imseih (AWS), Sami" <simseih@amazon.com>,
David Rowley <dgrowleyml@gmail.com>, Joe Conway <mail@joeconway.com>, Michael Banck <mbanck@gmx.net>, Laurenz Albe <laurenz.albe@cybertec.at>,
Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-11-06T12:51:07Z
Lists: pgsql-hackers
Hi frederic.yhuel > 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)); Frédéric Yhuel <frederic.yhuel@dalibo.com> 于2024年8月12日周一 21:41写道: > > > On 8/7/24 23:39, Nathan Bossart wrote: > > I've attached a new patch to show roughly what I think this new GUC > should > > look like. I'm hoping this sparks more discussion, if nothing else. > > > > 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. > > > On Tue, Jun 18, 2024 at 12:36:42PM +0200, Frédéric Yhuel wrote: > >> By the way, I wonder if there were any off-list discussions after > Robert's > >> conference at PGConf.dev (and I'm waiting for the video of the conf). > > > > I don't recall any discussions about this idea, but Robert did briefly > > mention it in his talk [0]. > > > > [0] https://www.youtube.com/watch?v=RfTD-Twpvac > > > > Very interesting, thanks! > > >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Introduce autovacuum_vacuum_max_threshold.
- 306dc520b9df 18.0 landed
-
Consolidate docs for vacuum-related GUCs in new subsection
- ca9c6a5680d7 18.0 cited