Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Nathan Bossart <bossartn@amazon.com>
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Andres Freund <andres@anarazel.de>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
"Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Michael Paquier <michael@paquier.xyz>,
Julien Rouhaud <rjuju123@gmail.com>,
Laurenz Albe <laurenz.albe@cybertec.at>,
"Jamison, Kirk" <k.jamison@jp.fujitsu.com>,
Amit Kapila <amit.kapila16@gmail.com>,
"Fujii
Masao" <masao.fujii@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-04T21:40:53Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add TRUNCATE parameter to VACUUM.
- b84dbc8eb80b 12.0 landed
-
Add vacuum_truncate reloption.
- 119dcfad988d 12.0 landed
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 cited
On 3/4/19, 12:11 PM, "Andres Freund" <andres@anarazel.de> wrote: > I'm not quite convinced this is right. There's plenty sites that > practically can't use autovacuum because it might decide to vacuum the > 5TB index because of 300 dead tuples in the middle of busy periods. And > without an reloption that's not controllable. Wouldn't it be better to adjust the cost and threshold parameters or to manually vacuum during quieter periods? I suppose setting DISABLE_INDEX_CLEANUP on a relation during busy periods could be useful if you really need to continue reclaiming transaction IDs, but that seems like an easy way to accidentally never vacuum indexes. Nathan