
> > You mean it is restored in session that is running the transaction ?

Depends on what you mean with restored. It first reads the heap page,
sees that it needs an older version and thus reads it from the "rollback segment".

> > 
> > I guess thet it could be slower than our current way of doing it.
> 
> Yes, for older transactions which *really* need in *particular*
> old data, but not for newer ones. Look - now transactions have to read
> dead data again and again, even if some of them (newer) need not to see
> those data at all, and we keep dead data as long as required for other
> old transactions *just for the case* they will look there.
> But who knows?! Maybe those old transactions will not read from table
> with big amount of dead data at all! So - why keep dead data in datafiles
> for long time? This obviously affects overall system performance.

Yes, that is a good description. And old version is only required in the following 
two cases:

1. the txn that modified this tuple is still open (reader in default committed read)
2. reader is in serializable transaction isolation and has earlier xtid

Seems overwrite smgr has mainly advantages in terms of speed for operations
other than rollback.

Andreas

Mon, 28 May 2001 10:02:17 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: Plans for solving the VACUUM problem
Zeugswetter Andreas SB wrote:
> 
> > > You mean it is restored in session that is running the transaction ?
> 
> Depends on what you mean with restored. It first reads the heap page,
> sees that it needs an older version and thus reads it from the "rollback segment".

So are whole pages stored in rollback segments or just the modified data
?

Storing whole pages could be very wasteful for tables with small records
that 
are often modified.

---------------
Hannu

Mon, 28 May 2001 11:11:46 +0200
Hannu Krosing <hannu@tm.ee>
Re: AW: Plans for solving the VACUUM problem
> Yes, that is a good description. And old version is only required in the following 
> two cases:
> 
> 1. the txn that modified this tuple is still open (reader in default committed read)
> 2. reader is in serializable transaction isolation and has earlier xtid
> 
> Seems overwrite smgr has mainly advantages in terms of speed for operations
> other than rollback.

... And rollback is required for < 5% transactions ...

Vadim



Mon, 28 May 2001 10:11:10 -0700
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: Plans for solving the VACUUM problem
> > > > You mean it is restored in session that is running the transaction ?
> > 
> > Depends on what you mean with restored. It first reads the heap page,
> > sees that it needs an older version and thus reads it from the "rollback segment".
> 
> 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.

Vadim



Mon, 28 May 2001 10:15:17 -0700
"Vadim Mikheev" <vmikheev@sectorbase.com>
Re: AW: Plans for solving the VACUUM problem
Vadim Mikheev wrote:
> 
> > Yes, that is a good description. And old version is only required in the following
> > two cases:
> >
> > 1. the txn that modified this tuple is still open (reader in default committed read)
> > 2. reader is in serializable transaction isolation and has earlier xtid
> >
> > Seems overwrite smgr has mainly advantages in terms of speed for operations
> > other than rollback.
> 
> ... And rollback is required for < 5% transactions ...

This obviously depends on application. 

I know people who rollback most of their transactions (actually they use
it to 
emulate temp tables when reporting). 

OTOH it is possible to do without rolling back at all as MySQL folks
have 
shown us ;)

Also, IIRC, pgbench does no rollbacks. I think that we have no
performance test that does.

-----------------
Hannu

Mon, 28 May 2001 19:41:40 +0200
Hannu Krosing <hannu@tm.ee>
Re: Plans for solving the VACUUM problem