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>, Don Baccus <dhogaza(at)pacifier(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'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-25 01:00:08
Message-ID: 200105250100.f4P108j23173@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> What I'm refering to is the discussion about the handling
> of subtransactions in order to introduce the savepoints
> functionality. Or do we postpone *savepoints* again ?
>
> I realize now few people have had the idea how to switch
> to an overwriting smgr. I don't think an overwriting smgr
> could be achived at once and we have to prepare one by one
> for it. AFAIK there's no idea how to introduce an overwriting
> smgr without UNDO. If we avoid UNDO now when overwriting smgr
> would appear ? I also think that the problems Andreas has
> specified are pretty serious. I also have known the problems
> and I've expected that people have the idea to solve it but
> ... I'm inclined to give up an overwriting smgr now.

Now that everyone has commented on the UNDO issue, I thought I would try
to summarize the comments so we can come to some kind of conclusion.

Here are the issues as I see them:

---------------------------------------------------------------------------

Do we want to keep MVCC?

Yes. No one has said otherwise.

---------------------------------------------------------------------------

Do we want to head for an overwriting storage manager?

Not sure.

Advantages: UPDATE has easy space reuse because usually done in-place,
no index change on UPDATE unless key is changed.

Disadvantages: Old records have to be stored somewhere for MVCC use.
Could limit transaction size.

---------------------------------------------------------------------------

Do we want UNDO _if_ we are heading for an overwriting storage manager?

Everyone seems to say yes.

---------------------------------------------------------------------------

Do we want UNDO if we are _not_ heading for an overwriting storage
manager?

This is the tough one. UNDO advantages are:

Make subtransactions easier by rolling back aborted subtransaction.
Workaround is using a new transactions id for each subtransaction.

Easy space reuse for aborted transactions.

Reduce size of pg_log.

UNDO disadvantages are:

Limit size of transactions to log storage size.

---------------------------------------------------------------------------

If we are heading for an overwriting storage manager, we may as well get
UNDO now. If we are not, then we have to decide if we can solve the
problems that UNDO would fix. Basically, can we solve those problems
easier without UNDO, or are the disadvanges of UNDO too great?

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2001-05-25 01:45:36 RE: Not released yet, but could someone take a quick peak ...
Previous Message Mikheev, Vadim 2001-05-25 00:23:19 RE: Plans for solving the VACUUM problem