On Sun, Nov 09, 2008 at 11:28:50PM -0500, Robert Haas wrote: > > 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.
ISTM the only reason why people are talking about page reservation is because people don't like the idea of an 8.4 backend being able to read 8.3 tuples without converting the whole page. If there's no hard dealine on the page conversion then you can let the 8.4 vacuum deal with it. Maybe it will take a few runs but it should get there eventually. I think you could probably sell page-reservation as: if you do this then upgrades will happen quicker but you shouldn't rely on people doing it as there are corner cases where it won't work. But if you ask people with multi-TB database whether they'll take a 1% CPU performance hit for never having to dump/restore again, which do you think they'll choose? For an I/O bound database the choice is easy. And if the performance is such a big deal provide two binaries, one to run during the upgrade and one once the upgrade is complete. Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature