Simon Riggs wrote:
> On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
>
>> Attached is a revamped version of the FSM rewrite. WAL-logging is now
>> gone. Any inconsistencies between levels of the FSM is fixed during
>> vacuum, and by searchers when they run into a dead end because of a
>> discrepancy. Corruption within FSM pages is likewise fixed by vacuum and
>> searchers.
>>
>> The FSM in a warm standby gets updated by replay of heap CLEAN WAL
>> records. That means that the FSM will reflect the situation after the
>> last vacuum, which is better than what we have now, but not quite
>> up-to-date. I'm worried that this might not be enough...
>
> I hadn't realised you would remove it completely. Did you identify WAL
> as the bottleneck?
No. But it seemed like a sensible thing to do.
> Is there some mid-way point between every time and almost never
> (VACUUM!)?
That's possible. However, if it's not fully WAL-logged, it needs to be
self-correcting, and probably needs to be periodically vacuumed as well.
So you'll get the code complexity of both approaches. I don't think
VACUUM in particular needs to be separately WAL-logged, because we can
easily piggy-back on the HEAP_CLEAN records. The question is whether we
should do the same for every heap insert and update record, or is that
too much overhead?
It looks like truncations do need to be WAL-logged, though.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
