Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 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.
> But you are assuming you have stuff in the free space map for the table
> already, right? I as not assuming that.
But that is going to be the normal state of affairs, at least for people
who don't reboot their postmasters every few minutes as we developers
tend to do.
Sure, you can point to situations where lazy VACUUM doesn't do as well
as full VACUUM. That's the point of having two implementations isn't it?
If we didn't need full VACUUM at all any more, we'd have removed it.
The existence of such situations is not justification for claiming that
lazy VACUUM isn't an appropriate default behavior. The question is
which one is more appropriate for typical installations under typical
operating conditions --- and in that sort of scenario there *will* be
info in the free space map.
Even more to the point, those typical installations do not want
exclusive-locked VACUUM. Haven't you paid any attention to the user
complaints we've been hearing for the last N years? People want a
nonexclusive VACUUM (or no VACUUM at all, but that's not a choice we can
offer them now.) That *is* what the typical dbadmin will want to run,
and that's why I say it should be the default. If you think that most
people will want to stick with exclusive VACUUM, I'd like to see some
evidence for that position (so that I know why the time I spent on that
project was wasted ;-)).
regards, tom lane
