Re: Name for new VACUUM

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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