Re: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Plans for solving the VACUUM problem
Date
Msg-id 200105250100.f4P108j23173@candle.pha.pa.us
Whole thread Raw
In response to Re: Plans for solving the VACUUM problem  (Hiroshi Inoue <Inoue@tpf.co.jp>)
List 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.
Workaroundis using a new transactions id for each subtransaction.Easy space reuse for aborted transactions.Reduce size
ofpg_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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Plans for solving the VACUUM problem
Next
From: "Christopher Kings-Lynne"
Date:
Subject: RE: Not released yet, but could someone take a quick peak ...