Re: Vacuum: allow usage of more than 1GB of work mem
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>,
Claudio Freire <klaussfreire@gmail.com>, Greg Stark <stark@mit.edu>,
Simon Riggs <simon@2ndquadrant.com>,
Jim Nasby <Jim.Nasby@bluetreble.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-15T16:22:16Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > On 09/14/2016 07:57 PM, Tom Lane wrote: >> People who are vacuuming because they are out of disk space will be very >> very unhappy with that solution. > The people are usually running out of space for data, while these files > would be temporary files placed wherever temp_tablespaces points to. I'd > argue if this is a source of problems, the people are already in deep > trouble due to sorts, CREATE INDEX, ... as those commands may also > generate a lot of temporary files. Except that if you are trying to recover disk space, VACUUM is what you are doing, not CREATE INDEX. Requiring extra disk space to perform a vacuum successfully is exactly the wrong direction to be going in. See for example this current commitfest entry: https://commitfest.postgresql.org/10/649/ Regardless of what you think of the merits of that patch, it's trying to solve a real-world problem. And as Robert has already pointed out, making this aspect of VACUUM more complicated is not solving any pressing problem. "But we made it faster" is going to be a poor answer for the next person who finds themselves up against the wall with no recourse. regards, tom lane
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited