Re: Savepoints

Bruce Momjian wrote:


> I am sorry.  I see what you are saying now.  I missed the words
> "overwriting smgr".  You are suggesting going to an overwriting storage
> manager.


Overwriting storage managers don't suffer from unbounded growth of 
datafiles until garbage collection (vacuum) is performed.  In fact, 
there's no need for a vacuum-style utility.  The rollback segments only 
need to keep around enough past history to rollback transactions that 
are executing.

Of course, then the size of your transactions are limited by the size of 
your rollback segments, which in Oracle are fixed in length when you 
build your database (there are ways to change this when you figure out 
that you didn't pick a good number when creating it).
>Is this to be done only because of savepoints.

Not in traditional storage managers such as Oracle uses.  The complexity 
of managing visibility and the like are traded off against the fact that 
you're not stuck ever needing to garbage collect a database that 
occupies a roomful of disks.

It's a trade-off.  PG's current storage manager seems to work awfully 
well in a lot of common database scenarios, and Tom's new vacuum is 
meant to help mitigate against the drawbacks.   But overwriting storage 
managers certainly have their advantages, too.
>  Doesn't seem

> worth it when I have a possible solution without such a drastic change.
> Also, overwriting storage manager will require MVCC to read through
> there to get accurate MVCC visibility, right?


Yep...

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org