> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
