Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-19T19:56:59Z
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
Michael Paquier wrote: > Then, let's consider the beginning of the first commit fest of v12 as > judgement. Implementing radix tree for shared buffers is a long-term > project, which has no guarantee to get merged, while a visibly-simple > reloptions which helps in some cases... In the scenario we studied, the truncations were causing periodic hiccups which were quite severe. The truncations were completely useless anyway because the table grew back to the original size daily (a few dozen GBs I think). That was a lot of unnecessary work, and under exclusive lock no less. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services