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 <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.