From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> |
Cc: | "The Hermit Hacker" <scrappy(at)hub(dot)org>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plans for solving the VACUUM problem |
Date: | 2001-05-21 04:32:42 |
Message-ID: | 20821.990419562@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Vadim Mikheev" <vmikheev(at)sectorbase(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christof Petig | 2001-05-21 09:01:01 | Re: C++ Headers |
Previous Message | Vadim Mikheev | 2001-05-21 03:06:15 | Re: Plans for solving the VACUUM problem |