From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Savepoints |
Date: | 2002-01-25 21:51:24 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA41EB4C5@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > How about: use overwriting smgr + put old records into rollback
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > segments - RS - (you have to keep them somewhere till TX's running
> > > anyway) + use WAL only as REDO log (RS will be used to
> rollback TX'
> > > changes and WAL will be used for RS/data files recovery).
> > > Something like what Oracle does.
> >
> > We have all the info we need in WAL and in the old rows,
> > why would you want to write them to RS ?
> > You only need RS for overwriting smgr.
>
> This is what I'm saying - implement Overwriting smgr...
Yes I am sorry, I am catching up on email and had not read Bruce's
comment (nor yours correctly) :-(
I was also long in the pro overwriting camp, because I am used to
non MVCC dbs like DB/2 and Informix. (which I like very much)
But I am starting to doubt that overwriting is really so good for
an MVCC db. And I don't think PG wants to switch to non MVCC :-)
Imho it would only need a much more aggressive VACUUM backend.
(aka garbage collector :-) Maybe It could be designed to sniff the
redo log (buffer) to get a hint at what to actually clean out next.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB SD | 2002-01-25 21:55:58 | Re: sequence indexes |
Previous Message | Zeugswetter Andreas SB SD | 2002-01-25 21:36:37 | Re: RFD: schemas and different kinds of Postgres objects |