
> Note that I don't talk about overwriting/non-overwriting smgr at all!
> It's not issue. There are no problems with keeping dead 
> tuples in files
> as long as required. When I told about new smgr I meant 
> ability to re-use
> space without vacuum and store > 1 tables per file.
> But I'll object storing transaction commit times in tuple header and
> old-designed pg_time. If you want to do TT - welcome... but make
> it optional, without affect for those who need not in TT.

Thank you for explaining, I did not see that as a possibility. 
Now, if we had a possibility to tune/specify what is allowed to be 
overwritten, then an online OS backup would still be possible 
with that design, maybe even some limited TT.

But: I do think that if we are going towards overwrite smgr, then the
only way that we also gain the advantages of it, is to update inplace.
1. index update only if indexed column changes
2. reduce IO (many updates to one row --> only one data write)

Andreas

Wed, 12 Jul 2000 18:57:57 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: postgres 7.2 features.