From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, 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 19:55:25 |
Message-ID: | 4911FA2D.2070303@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout napsal(a):
> On Wed, Nov 05, 2008 at 03:04:42PM +0100, Zdenek Kotala wrote:
>> Greg Stark napsal(a):
>> 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.
>
> Is this really such a big deal? You do the null-update on the last
> tuple of the page and then you do have enough room. So Phase one moves
> a few tuples to make room. Phase 2 actually converts the pages inplace.
Problem is how to move tuple from page to another and keep indexes in sync. One
solution is to perform some think like "update" operation on the tuple. But you
need exclusive lock on the page and pin counter have to be zero. And question is
where it is safe operation.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-11-05 19:55:55 | A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD |
Previous Message | Heikki Linnakangas | 2008-11-05 19:49:08 | Toast bug in CVS HEAD |