Thread

1. AW: Storage Manager (was postgres 7.2 features.)

   Zeugswetter Andreas SB <zeugswettera@wien.spardat.at> — 2000-07-11T14:09:18Z

   > > * It's always faster than WAL in the presence of stable main memory.
   > > (Whether the stable caches in modern disk drives is an 
   > approximation I
   > > don't know).
   > 
   >     For writing, yes. But for high updated tables, the scans will
   >     soon slow down due to the junk contention.
   
   Can you elaborate please ? If we centralized writes, then the
   non-overwrite smgr would be very efficient since it only writes to the end 
   of a table (e.g. one page write for pagesize/rowsize rows). 
   
   > 
   > > * It's more scalable and has less logging contention. This allows
   > > greater scalablility in the presence of multiple processors.
   > >
   > > * Instantaneous crash recovery.
   > 
   >     Because  this never worked reliable, Vadim is working on WAL
   
   crash recovery is bullet proof. the WAL is only needed for rollforward 
   after restore with our non overwrite smgr. 
   I do agree that we need a txlog. 
   
   Andreas
   
   

2. Re: AW: Storage Manager (was postgres 7.2 features.)

   Jan Wieck <janwieck@t-online.de> — 2000-07-11T16:41:39Z

   Zeugswetter Andreas SB wrote:
   >
   > > > * It's always faster than WAL in the presence of stable main memory.
   > > > (Whether the stable caches in modern disk drives is an
   > > approximation I
   > > > don't know).
   > >
   > >     For writing, yes. But for high updated tables, the scans will
   > >     soon slow down due to the junk contention.
   >
   > Can you elaborate please ? If we centralized writes, then the
   > non-overwrite smgr would be very efficient since it only writes to the end
   > of a table (e.g. one page write for pagesize/rowsize rows).
   
       Each  UPDATE/DELETE  does  a  scan,  which  will  be the more
       expensive the larger the heap grows (more tuples to visit  on
       sequential  access,  farer  head  seeks on indexed ones). And
       each SELECT does the same.
   
   > > > * It's more scalable and has less logging contention. This allows
   > > > greater scalablility in the presence of multiple processors.
   > > >
   > > > * Instantaneous crash recovery.
   > >
   > >     Because  this never worked reliable, Vadim is working on WAL
   >
   > crash recovery is bullet proof. the WAL is only needed for rollforward
   > after restore with our non overwrite smgr.
   > I do agree that we need a txlog.
   
       Need to precisely define CRASH here. Meant OS/system crashes,
       where you may loose integrity of filesystems as well. This is
       not the fault of the DB, but if a user/client got  a  "COMMIT
       is  OK",  he  should be able to forget about it and go ahead.
       With backup and xlog you can place DB and xlog  on  different
       raid  arrays,  still  not  bullet proof (someone might use an
       automatic gun to shootdown), but alot better.
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #================================================== JanWieck@Yahoo.com #