> > > How about: use overwriting smgr + put old records into rollback
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > segments - RS - (you have to keep them somewhere till TX's running
> > > anyway) + use WAL only as REDO log (RS will be used to
> rollback TX'
> > > changes and WAL will be used for RS/data files recovery).
> > > Something like what Oracle does.
> >
> > We have all the info we need in WAL and in the old rows,
> > why would you want to write them to RS ?
> > You only need RS for overwriting smgr.
>
> This is what I'm saying - implement Overwriting smgr...
Yes I am sorry, I am catching up on email and had not read Bruce's
comment (nor yours correctly) :-(
I was also long in the pro overwriting camp, because I am used to
non MVCC dbs like DB/2 and Informix. (which I like very much)
But I am starting to doubt that overwriting is really so good for
an MVCC db. And I don't think PG wants to switch to non MVCC :-)
Imho it would only need a much more aggressive VACUUM backend.
(aka garbage collector :-) Maybe It could be designed to sniff the
redo log (buffer) to get a hint at what to actually clean out next.
Andreas
