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