Re: Plans for solving the VACUUM problem

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

In response to

Responses

Browse pgsql-hackers by date

  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