VACUUM DATABASE

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: VACUUM DATABASE
Date: 2005-07-26 20:30:20
Message-ID: 1122409820.3670.40.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I'd like to suggest altering the syntax of VACUUM so that it is possible
to issue the command VACUUM DATABASE. The keyword DATABASE would be
optional, to allow backward compatibility.

The reasons for this are better understanding and comprehension. Soooo
many people are confused about the differences between the various types
of VACUUM, even after they have looked in the manual (which many people
do not, lets be honest).

There is much confusion over the instruction that people need to VACUUM
regularly means "VACUUM". Not VACUUM <table> or VACUUM FULL, but VACUUM.
They generally take the keyword as a generic solution, rather than an
exact command, especially when there are other specific variants. (Just
like if I said, use ALTER TABLE, you would know I meant the generic, not
literally to type "ALTER TABLE".)

The next question is always why a "full database VACUUM" is not
necessarily conducted with the VACUUM FULL command - thats something
different...

So the new syntax would allow us to differentiate between a VACUUM FULL
and a VACUUM DATABASE much more easily.

Anyway, by describing a lazy vacuum of the whole database as a VACUUM
DATABASE, we now can more easily explain to everybody which command
needs to be run in order to avoid transaction wraparound. I would
propose updating the manual to consistently refer to the new term.

My experience is that the majority of users are very, very confused as
to what the various types of VACUUM do. Probably a good reason why we
have autovacuum, but still worth mentioning, IMHO.

Fear? Loathing?

Best Regards, Simon Riggs

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-07-26 20:33:35 Re: For review: Server instrumentation patch
Previous Message Jim C. Nasby 2005-07-26 20:22:35 ENUM type