| 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: | Whole Thread | Raw Message | 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. |