Gaetano Mendola <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq