Re: Vacuum: allow usage of more than 1GB of work mem
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Pavan Deolasee <pavan.deolasee@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.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:40:18Z
Lists: pgsql-hackers
On Thu, Sep 15, 2016 at 12:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. I very much agree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited