On Wed, 2006-02-08 at 11:55 -0800, Josh Berkus wrote:
> One justification for in-place upgrades is to be faster than
> dump/reload. However, if we're assuming the possibility of new/modified
> header fields which could then cause page splits on pages which are 90%
> capacity, then this time savings would be on the order of no more than
> 50% of load time
Well, if you need to start shuffling heap tuples around, you also need
to update indexes, in addition to rewriting all the heap pages. This
would require work on the order of VACUUM FULL in the worst case, which
is pretty expensive.
However, we don't change the format of heap or index pages _that_ often.
An in-place upgrade script that worked when the heap/index page format
has not changed would still be valuable -- only the system catalog
format would need to be modified.
> The second reason for in-place upgrade is for large databases where the
> owner does not have enough disk space for two complete copies of the
> database. Again, this is not solvable; if we want in-place upgrade to
> be fault-tolerant, then we need the doubled disk space anyway
When the heap/index page format hasn't changed, we would only need to
backup the system catalogs, which would be far less expensive.
-Neil
