| From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "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>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Plans for solving the VACUUM problem |
| Date: | 2001-05-23 23:15:06 |
| Message-ID: | 3B0C447A.E6EF4AF3@tpf.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> >> I guess that is the question. Are we heading for an overwriting storage
> >> manager?
>
> > I've never heard that it was given up. So there seems to be
> > at least a possibility to introduce it in the future.
>
> Unless we want to abandon MVCC (which I don't), I think an overwriting
> smgr is impractical.
Impractical ? Oracle does it.
> We need a more complex space-reuse scheme than
> that.
>
IMHO we have to decide which to go now.
As I already mentioned, changing current handling
of transactionId/CommandId to avoid UNDO is not
only useless but also harmful for an overwriting
smgr.
regards,
Hiroshi Inoue
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Don Baccus | 2001-05-23 23:24:48 | Re: Plans for solving the VACUUM problem |
| Previous Message | Bruce Momjian | 2001-05-23 22:57:52 | Re: C++ Headers |