AW: AW: Plans for solving the VACUUM problem

> > > > So are whole pages stored in rollback segments or just
> > > > the modified data?
> > > 
> > > This is implementation dependent. Storing whole pages is
> > > much easy to do, but obviously it's better to store just
> > > modified data.
> > 
> > I am not sure it is necessarily better. Seems to be a tradeoff here.
> > pros of whole pages:
> >     a possible merge with physical log (for first
> >           modification of a page after checkpoint
> >         there would be no overhead compared to current 
> >           since it is already written now)
> 
> Using WAL as RS data storage is questionable.

No, I meant the other way around. Move the physical log pages away from WAL 
files to the "rollback segment" (imho "snapshot area" would be a better name)

> >     in a clever implementation a page already in the
> >           "rollback segment" might satisfy the 
> >         modification of another row on that page, and 
> >           thus would not need any additional io.
> 
> This would be possible only if there was no commit (same SCN)
> between two modifications.

I don't think someone else's commit matters unless it touches the same page.
In that case a reader would possibly need to chain back to an older version 
inside the snapshot area, and then it gets complicated even in the whole page 
case. A good concept could probably involve both whole page and change
only, and let the optimizer decide what to do.

> But, aren't we too deep on overwriting smgr (O-smgr) implementation?

Yes, but some understanding of the possibilities needs to be sorted out 
to allow good decicsions, no ?

Andreas