Re: Proposal "VACUUM SCHEMA" - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Proposal "VACUUM SCHEMA"
Date
Msg-id 549782C0.7050607@BlueTreble.com
Whole thread Raw
In response to Re: Proposal "VACUUM SCHEMA"  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Responses Re: Proposal "VACUUM SCHEMA"  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List pgsql-hackers
On 12/21/14, 3:30 PM, Fabrízio de Royes Mello wrote:
>
> On Sun, Dec 21, 2014 at 5:18 PM, Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
>  >
>  > Fabrízio de Royes Mello <fabriziomello@gmail.com <mailto:fabriziomello@gmail.com>> writes:
>  > > I work with some customer that have databases with a lot of schemas and
>  > > sometimes we need to run manual VACUUM in one schema, and would be nice to
>  > > have a new option to run vacuum in relations from a specific schema.
>  >
>  > I'm pretty skeptical of this alleged use-case.  Manual vacuuming ought
>  > to be mostly a thing of the past, and even if it's not, hitting
>  > *everything* in a schema should seldom be an appropriate thing to do.
>  >
>
> I agree manual vacuum is a thing of the past, but autovacuum doesn't solve 100% of the cases, and sometimes we need
touse it so my proposal is just do help DBAs and/or Sysadmins to write simple maintenance scripts.
 

Just one example of that is pre-emptively vacuuming during slower periods. Nothing spells "fun" like a freeze vacuum in
themiddle of a busy lunch period for a website.
 

Similarly, it's common to need to proactively vacuum after a data load, and since it's not unusual for there to be a
schemadedicated to loading data, this makes that easier.
 

>  > And why that, but not
>  > say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
>  >
>
> +1. I can write patches for each of this maintenance statement too.

If we're going to go that route, then perhaps it would make more sense to create a command that allows you to apply a
secondcommand to every object in a schema. We would have to be careful about PreventTransactionChain commands.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Michael Paquier
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}