
> > * 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

Tue, 11 Jul 2000 16:09:18 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Storage Manager (was postgres 7.2 features.)
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 #



Tue, 11 Jul 2000 18:41:39 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: AW: Storage Manager (was postgres 7.2 features.)