Skip site navigation (1) Skip section navigation (2)


From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Date: 2005-07-26 20:30:20
Message-ID: 1122409820.3670.40.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
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

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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group