Re: Proposal: Multiversion page api (inplace upgrade)

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Multiversion page api (inplace upgrade)
Date: 2008-06-13 08:27:19
Message-ID: 48522F67.7080809@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ron Mayer napsal(a):
> Tom Lane wrote:
>> Another issue is that it might not be possible to update a page for
>> lack of space. Are we prepared to assume that there will never be a
>> transformation we need to apply that makes the data bigger? In such a
>> situation an in-place update might be impossible, and that certainly
>> takes it outside the bounds of what ReadBuffer can be expected to manage.
>
> Would a possible solution to this be that you could
>

<snip>

>
> 2. Run some new maintenance command like "vacuum expand" or
> "vacuum prepare_for_upgrade" or something that would split
> any too-full pages, leaving only pages with enough space.

It does not solve problems for example with TOAST tables. If chunks does not fit
on a new page layout one of the chunk tuple have to be moved to free page. It
means you get a lot of pages with ~2kB of free unused space. And if max chunk
size is different between version you got another problem as well.

There is also idea to change compression algorithm for 8.4 (or offer more
varinats). It also mean that you need to understand old algorithm in a new
version or you need to repack everything on old version.

Zdenek

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ITAGAKI Takahiro 2008-06-13 08:33:18 pg_stat_statements
Previous Message Andrew Dunstan 2008-06-13 04:35:33 Re: default client encoding in postgresql.conf