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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
>
> 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.

Huh, so why not have an optional LAZY?

I understand your concern against "VACUUM LAZY table", which is not
helpful -- so your advice would have to be rephrased as "issue a
database-wide lazy vacuum"

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Saca el libro que tu religión considere como el indicado para encontrar la
oración que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona" (Carlos Duclós)

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Simon Riggs <simon@2ndquadrant.com> writes:
> 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.

This would require converting DATABASE from an unreserved keyword into
a fully reserved keyword (else the parser couldn't tell whether you
were asking for a vacuum of a single table named "database"). That
seems to me like a change moderately likely to break existing
applications ... not that I'd ever name a table, column, function,
type, or schema "database", but I'll bet somebody out there has.

I don't really see the argument that "let's make life easier for people
who didn't read the manual" trumps "let's not break applications that
chose legitimate object names".

Perhaps we need some work on the documentation instead...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Tuesday 26 July 2005 16:53, Alvaro Herrera wrote:
> On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
> > 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.
>
> Huh, so why not have an optional LAZY?
>
> I understand your concern against "VACUUM LAZY table", which is not
> helpful -- so your advice would have to be rephrased as "issue a
> database-wide lazy vacuum"

Simon,
While I don't think I would advocate the term "vacuum lazy", istm that
alvarro is on the right track. With your syntax, I would have figured there
would have been a vacuum full database. The term database seems to
differentiate between vacuuming the complete database from vacuuming tables,
but what I think you're after is differntiating between FULL and
"non-full/lazy" vacuums. Maybe you're after both?

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Wed, 2005-07-27 at 00:07 -0400, Robert Treat wrote:
> On Tuesday 26 July 2005 16:53, Alvaro Herrera wrote:
> > On Tue, Jul 26, 2005 at 09:30:20PM +0100, Simon Riggs wrote:
> > > 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.
> >
> > Huh, so why not have an optional LAZY?
> >
> > I understand your concern against "VACUUM LAZY table", which is not
> > helpful -- so your advice would have to be rephrased as "issue a
> > database-wide lazy vacuum"
>
> With your syntax, I would have figured there
> would have been a vacuum full database.

Yes

> The term database seems to
> differentiate between vacuuming the complete database from vacuuming tables,

Exactly what I meant.

> but what I think you're after is differentiating between FULL and
> "non-full/lazy" vacuums. Maybe you're after both?

No, I just used the term lazy because that is how it is referred to
within the code. I'm happy that there are two kinds of vacuum, lazy and
full and that we differentiate between them by using the FULL keyword.

Forgive me if this is wrong, but I took that Alvaro was applying a
"reductio ad absurdum" argument (i.e. taking the piss). I laughed
heartily at the thought of LAZY becoming a PostgreSQL keyword.

Anyway, I think it shows how confusing the subject is when I can't
easily explain to you what I mean.

Best Regards, Simon Riggs


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Wed, Jul 27, 2005 at 11:41:24PM +0100, Simon Riggs wrote:

> Forgive me if this is wrong, but I took that Alvaro was applying a
> "reductio ad absurdum" argument (i.e. taking the piss). I laughed
> heartily at the thought of LAZY becoming a PostgreSQL keyword.

Ah, well, actually you are wrong, I was really suggesting that keyword
because that's what we call the feature. It doesn't sound that bad to
me, but if you laughed at it then maybe it's really a bad idea.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"All rings of power are equal,
But some rings of power are more equal than others."
(George Orwell's The Lord of the Rings)

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Wed, 2005-07-27 at 19:09 -0400, Alvaro Herrera wrote:
> On Wed, Jul 27, 2005 at 11:41:24PM +0100, Simon Riggs wrote:
>
> > Forgive me if this is wrong, but I took that Alvaro was applying a
> > "reductio ad absurdum" argument (i.e. taking the piss). I laughed
> > heartily at the thought of LAZY becoming a PostgreSQL keyword.
>
> Ah, well, actually you are wrong, I was really suggesting that keyword
> because that's what we call the feature. It doesn't sound that bad to
> me, but if you laughed at it then maybe it's really a bad idea.

Then I apologize, but agree with your conclusion.

I think a headline of "PostgreSQL gets LAZY" would be irresistable for
the online news scream-sheets.

Best Regards, Simon Riggs


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster