Re: Proposal "VACUUM SCHEMA"

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: Proposal "VACUUM SCHEMA"
Дата
Msg-id CAFcNs+qR53xD+1J6yn+ZrFpPHEiGnz47N2kJSX_wQUwv3aattw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal "VACUUM SCHEMA"  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Proposal "VACUUM SCHEMA"  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers


Em segunda-feira, 22 de dezembro de 2014, Jim Nasby <Jim.Nasby@bluetreble.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@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 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: PATCH: decreasing memory needlessly consumed by array_agg
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Re[3]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code