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

From Mikheev, Vadim
Subject RE: Plans for solving the VACUUM problem
Date
Msg-id 3705826352029646A3E91C53F7189E32016656@sectorbase2.sectorbase.com
Whole thread Raw
In response to Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: Plans for solving the VACUUM problem  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
> 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.

Really? Why is it assumed that we *must* limit size of rollback segments?
We can let them grow without bounds, as we do now keeping old records in
datafiles and letting them eat all of disk space.

> UNDO disadvantages are:
> 
>     Limit size of transactions to log storage size.

Don't be kidding - in any system transactions size is limitted
by available storage. So we should tell that more disk space
is required for UNDO. From my POV, putting $100 to buy 30Gb
disk is not big deal, keeping in mind that PGSQL requires
$ZERO to be used.

Vadim


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GiST index on data types that require compression
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: Plans for solving the VACUUM problem