> > People also have referred to an overwriting smgr
> > easily. Please tell me how to introduce an overwriting smgr
> > without UNDO.
There is no way. Although undo for an overwriting smgr would involve a
very different approach than with non-overwriting. See Vadim's post about what
info suffices for undo in non overwriting smgr (file and ctid).
> I guess that is the question. Are we heading for an overwriting storage
> manager? I didn't see that in Vadim's list of UNDO advantages, but
> maybe that is his final goal. If so UNDO may make sense, but then the
> question is how do we keep MVCC with an overwriting storage manager?
>
> The only way I can see doing it is to throw the old tuples into the WAL
> and have backends read through that for MVCC info.
If PostgreSQL wants to stay MVCC, then we should imho forget "overwriting smgr"
very fast.
Let me try to list the pros and cons that I can think of:
Pro:no index modification if key stays sameno search for free space for update (if tuple still fits into page)no
pg_log
Con:additional IO to write "before image" to rollback segment (every before image, not only first after checkpoint)
(also before image of every index page that is updated !)need a rollback segment that imposes all sorts of contention
problemsactiverollback, that needs to do a lot of undo work
Andreas
