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