Gaetano Mendola <mendola@bigfoot.com> writes:
> Richard Huxton wrote:
>> If page number 8549 was the one being held, I don't think vacuum can
>> truncate the file. The empty space can be re-used, but the rows can't be
>> moved to a lower page while a transaction is using them.
> It's clear now.
Not entirely. VACUUM FULL doesn't really worry about whether anyone
else "is using" the table --- it knows no one else is, because it holds
exclusive lock on the table. However it must preserve dead tuples that
would still be visible to any existing transaction, because that other
transaction could come along and look at the table after VACUUM
finishes and releases the lock.
What really drives the process is that VACUUM FULL moves tuples in order
to make the file shorter (release empty pages at the end) --- and not
for any other reason. So it could stop when there is still plenty of
dead space in the table. It stops when the last nonempty page contains
a tuple that it can't find room for in any earlier page.
What I suppose you saw was that page 8503 contained a tuple so large it
wouldn't fit in the free space on any earlier page. By the time of the
second vacuum, either this tuple was deleted, or deletion of some other
tuples had made a hole big enough for it to fit in.
The extent of the truncation in the second vacuum says that you had
quite a lot of free space, so it's a bit surprising that there wasn't
enough room in any one page for such a tuple to be moved, but that seems
to be what happened.
regards, tom lane