"Vadim Mikheev" <vmikheev@sectorbase.com> writes:
> Unfortunately, I think that we'll need in on-disk FSM and that FSM is
> actually the most complex thing to do in "space reclamation" project.
I hope we can avoid on-disk FSM. Seems to me that that would create
problems both for performance (lots of extra disk I/O) and reliability
(what happens if FSM is corrupted? A restart won't fix it).
But, if we do need it, most of the work needed to install FSM APIs
should carry over. So I still don't see an objection to doing
in-memory FSM as a first step.
BTW, I was digging through the old Postgres papers this afternoon,
to refresh my memory about what they actually said about VACUUM.
I was interested to discover that at one time the tuple-insertion
algorithm went as follows: 1. Pick a page at random in the relation, read it in, and see if it has enough free
space. Repeat up to three times. 2. If #1 fails to find space, append tuple at end.
When they got around to doing some performance measurement, they
discovered that step #1 was a serious loser, and dropped it in favor
of pure #2 (which is what we still have today). Food for thought.
regards, tom lane
