Re: Recording vacuum/analyze/dump times
От | Jim Buttafuoco |
---|---|
Тема | Re: Recording vacuum/analyze/dump times |
Дата | |
Msg-id | 20050307184040.M47550@contactbda.com обсуждение исходный текст |
Ответ на | Re: Recording vacuum/analyze/dump times (Heikki Linnakangas <hlinnaka@iki.fi>) |
Список | pgsql-hackers |
This is what I was thinking about doing. It would be nicer if the system "just did it" for me. I have 100+'s of databases with 100+'s of tables in each and run pg_autovacuum on them all. I also do nightly dumps and any database that has been modified (my application keeps track). I was just thinking of using these dates as a check that the automated processes are working. Jim ---------- Original Message ----------- From: Heikki Linnakangas <hlinnaka@iki.fi> To: Jim Buttafuoco <jim@contactbda.com> Cc: pgsql-hackers@postgresql.org Sent: Mon, 7 Mar 2005 20:35:21 +0200 (EET) Subject: Re: [HACKERS] Recording vacuum/analyze/dump times > On Mon, 7 Mar 2005, Jim Buttafuoco wrote: > > > Its there a reason postgresql doesn't record vacuum/analyze and dump times in pg_class (or another table). This seems > > like it would be a very helpful feature. > > > > for pg_dump I would add an option --record=YES|NO > > for vacuum and analyze I would add a NORECORD|RECORD option > > You could easily do this in application level: > > CREATE TABLE vacuums (relname name, last_vacuum timestamp); > > Every time you vacuum, do: > > VACUUM foobar; UPDATE dumps set last_dump = now() WHERE relname = 'foobar'; > > Same for pg_dump. > > - Heikki > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org ------- End of Original Message -------
В списке pgsql-hackers по дате отправления: