Mike Mascari <mascarm@mascari.com> writes:
> Very neat. You mention that the truncation of both heap and index
> relations is not necessarily mandatory. Under what conditions would
> either of them be truncated?
In the proposal as given, a heap file would be truncated if (a) it
has at least one totally empty block at the end, and (b) no other
transaction is touching the table at the instant that VACUUM is
ready to truncate it.
This would probably be fairly infrequently true, especially for
heavily used tables, but if you believe in a "steady state" analysis
then that's just fine. No point in handing blocks back to the OS
only to have to allocate them again soon.
We might want to try to tilt the FSM-driven reuse of freed space
to favor space near the start of the file and avoid end blocks.
Without that, you might never get totally free blocks at the end.
The same comments hold for index blocks, with the additional problem
that the index structure would make it almost impossible to drive usage
away from the physical end-of-file. For btrees I think it'd be
sufficient if we could recycle empty blocks for use elsewhere in the
btree structure. Actually shrinking the index probably won't happen
short of a REINDEX.
regards, tom lane
