Re: FSM, now without WAL-logging
От | Heikki Linnakangas |
---|---|
Тема | Re: FSM, now without WAL-logging |
Дата | |
Msg-id | 48D9F302.2060902@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: FSM, now without WAL-logging (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: