Re: 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(at)Yahoo(dot)com #