From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Chris Bitmead'" <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>, pgsql-hackers(at)hub(dot)org |
Subject: | RE: Storage Manager (was postgres 7.2 features.) |
Date: | 2000-07-11 19:06:35 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A23018C55@SECTORBASE1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > * 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).
>
> Yes, only if you want to be able to log changes to a txlog to
> be able to rollforward changes after a restore, then that benefit
> is not so large any more.
I'm going to implement rollback as well... Without compensation records...
> > * It's more scalable and has less logging contention. This allows
> > greater scalablility in the presence of multiple processors.
>
> Same as above, if you want a txlog you lose.
> But if we could switch the txlog off then at least in that mode
> we would keep all benefits of the non-overwrite smgr.
WAL allows "batch commit" (log commit record, then sleep for ~1/200 sec,
now write/fsync log... if no one else didn't fsync-ed it already...)
> > * Time travel is available at no cost.
>
> Yes. Yes, it also solves MVCC.
Not with 1sec time grain...
But 6+6 bytes per tuple would be enough.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2000-07-11 19:24:13 | Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashesbackend.) |
Previous Message | Mikheev, Vadim | 2000-07-11 18:54:10 | RE: postgres 7.2 features. |