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
aboutit and go ahead. With backup and xlog you can place DB and xlog on different raid arrays, still not
bulletproof (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 #
