From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plans for solving the VACUUM problem |
Date: | 2001-05-23 00:53:23 |
Message-ID: | 200105230053.f4N0rNY17041@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Looking at the previous features you added, like subqueries, MVCC, or
> > WAL, these were major features that greatly enhanced the system's
> > capabilities.
> >
> > Now, looking at UNDO, I just don't see it in the same league as those
> > other additions.
>
> Hmm hasn't it been an agreement ? I know UNDO was planned
> for 7.0 and I've never heard objections about it until
> recently. People also have referred to an overwriting smgr
> easily. Please tell me how to introduce an overwriting smgr
> without UNDO.
I guess that is the question. Are we heading for an overwriting storage
manager? I didn't see that in Vadim's list of UNDO advantages, but
maybe that is his final goal. If so UNDO may make sense, but then the
question is how do we keep MVCC with an overwriting storage manager?
The only way I can see doing it is to throw the old tuples into the WAL
and have backends read through that for MVCC info.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2001-05-23 00:59:57 | |
Previous Message | Hiroshi Inoue | 2001-05-23 00:49:33 | Re: Plans for solving the VACUUM problem |