Zeugswetter Andreas SB SD wrote:
>
> > Now, with MVCC, the backend has to read through the redo segment to get
>
> You mean rollback segment, but ...
Sorry, yes. I get redo/undo/rollback mixed up sometimes. :-)
> > the original data value for that row.
>
> Will only need to be looked up if the row is currently beeing modified by
> a not yet comitted txn (at least in the default read committed mode)
Uh, not really. The transaction may have completed after my transaction
started, meaning even though it looks like it is committed, to me, it is
not visible. Most MVCC visibility will require undo lookup.
>
> >
> > Now, while rollback segments do help with cleaning out old UPDATE rows,
> > how does it improve DELETE performance? Seems it would just mark it as
> > expired like we do now.
>
> delete would probably be:
> 1. mark original deleted and write whole row to RS
>
> I don't think you would like to mix looking up deleted rows in heap
> but updated rows in RS
Yes, so really the overwriting is only a big win for UPDATE. Right now,
UPDATE is DELETE/INSERT, and that DELETE makes MVCC happy. :-)
My whole goal was to simplify this so we can see the differences.
> PS: not that I like overwrite with MVCC now
> If you think of VACUUM as garbage collection PG is highly trendy with
> the non-overwriting smgr.
Yes, that is basically what it is now, a garbage collector that collects
in heap rather than in undo.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
