> I think so too. I've never said that an overwriting smgr
> is easy and I don't love it particularily.
> 
> What I'm objecting is to avoid UNDO without giving up
> an overwriting smgr. We shouldn't be noncommittal now. 

Why not? We could decide to do overwriting smgr later
and implement UNDO then. For the moment we could just
change checkpointer to use checkpoint.redo instead of
checkpoint.undo when defining what log files should be
deleted - it's a few minutes deal, and so is changing it
back.

Vadim

Thu, 24 May 2001 10:57:19 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Plans for solving the VACUUM problem
"Mikheev, Vadim" wrote:
> 
> > I think so too. I've never said that an overwriting smgr
> > is easy and I don't love it particularily.
> >
> > What I'm objecting is to avoid UNDO without giving up
> > an overwriting smgr. We shouldn't be noncommittal now.
> 
> Why not? We could decide to do overwriting smgr later
> and implement UNDO then.

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.

regards,
Hiroshi Inoue

Fri, 25 May 2001 08:51:44 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Plans for solving the VACUUM problem
> 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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 24 May 2001 21:00:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Plans for solving the VACUUM problem