Re: Proposal "VACUUM SCHEMA"

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal "VACUUM SCHEMA"
Date: 2014-12-22 02:55:14
Message-ID: CAFcNs+qR53xD+1J6yn+ZrFpPHEiGnz47N2kJSX_wQUwv3aattw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em segunda-feira, 22 de dezembro de 2014, Jim Nasby <
Jim(dot)Nasby(at)bluetreble(dot)com> escreveu:

> 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(at)sss(dot)pgh(dot)pa(dot)us <mailto:
>> tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>> >
>> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com
>> <mailto:fabriziomello(at)gmail(dot)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 to use 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 the middle 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 schema dedicated to loading
> data, this makes that easier.

Good example. Thanks.

>
> > 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 second command to every object
> in a schema. We would have to be careful about PreventTransactionChain
> commands.

Sorry but I don't understand what you meant. Can you explain more about
your idea?

Regards,

Fabrízio Mello

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-22 03:07:06 Re: Re[3]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Previous Message Jim Nasby 2014-12-22 02:44:32 Re: PATCH: decreasing memory needlessly consumed by array_agg