Re: Name for new VACUUM

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Not necessarily.  Concurrent VACUUM does truncate the relation if it can
>> do so conveniently --- for example, it will successfully reclaim space
>> if you do "DELETE FROM foo; VACUUM foo;".  It just doesn't try as hard
>> as the older VACUUM code does.

> But it will not reclaim from UPDATE.

What?  I have no idea what you mean by that.

>  You also will have to VACUUM
> NOLOCK right after your delete or the next INSERT is going to go on the
> end and VACUUM NOLOCK is not going to compact the table, right?

INSERTs don't go on the end in the first place, at least not under
steady-state conditions.  That's what the free space map is all about.

> My contention is that we are causing more problems for administrators by
> changeing VACUUM's default behavior.

This is a curious definition of causing problems: making it work better
is causing a problem?  I didn't think we'd elevated backwards
compatibility to quite that much of a holy grail.  To me, a backwards
compatibility problem is something that actually breaks an existing app.
I do not see how changing vacuum's default behavior will break anything.

>> Right now it's called VACUUM FULL, but I'm not particularly wedded to
>> that name.  Does anyone else like VACUUM LOCK?  Or have an even better
>> idea?

> FULL seems overloaded to me.  Maybe LOCK or FORCE.

LOCK is pretty overloaded too, but I don't have any other objection to
it.  "FORCE" is meaningless; what are you forcing, and just how much
force are you applying?
        regards, tom lane