From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] In-place upgrade |
Date: | 2008-11-05 14:04:42 |
Message-ID: | 4911A7FA.1030805@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark napsal(a):
> I don't think this really qualifies as "in place upgrade" since it would
> mean creating a whole second copy of all your data. And it's only online
> got read-only queries too.
>
> I think we need a way to upgrade the pages in place and deal with any
> overflow data as exceptional cases or else there's hardly much point in
> the exercise.
It is exceptional case between V3 and V4 and only on heap, because you save in
varlena. But between V4 and V5 we will lost another 4 bytes in a page header ->
page header will be 28 bytes long but tuple size is same.
Try to get raw free space on each page in 8.3 database and you probably see a
lot of pages where free space is 0. My last experience is something about 1-2%
of pages.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-11-05 14:12:52 | Re: array_length() |
Previous Message | Simon Riggs | 2008-11-05 14:01:58 | Re: Synchronous replication patch v1 |