> Well, if that's what it is, I think it's a fairly poor design
> decision. When I upgrade Oracle, SQL Server, or MySQL, I don't need
> to plan the amount of free space in my blocks a year or more before an
> upgrade. In fact, I don't have to plan it at all... it's completely
> handled by the in-place upgrade.
Well, I think the proposal is that you would change the amount of free
space in your blocks immediately prior to performing the upgrade, but
I still think it's a poor decision to make in-place upgrade dependent
on support from the OLD version of the code.
Let's suppose, for example, that in 8.5 we decide to change some type
that is presently 16 bits to 32 bits, or 8 bits to 16 bits, etc. This
will make some tuples bigger, and potentially much bigger, but since
it presumably won't be a commonly used data-type, most tuples won't
change at all. However, the worst case scenario for how much free
space you might need to reserve will be very bad, and therefore a
mechanism that allows reserving a fixed amount of free space per page
won't be adequate.
Now, maybe someone will come up with some reason why that particular
example is unlikely or impossible or can be worked around. But there
are LOTS of imaginable scenarios that could cause unpredictable
amounts of page expansion or contraction, and I find it hard to
believe that we can be confident that NONE of those things will EVER
happen.
...Robert
