Re: Proposal: Multiversion page api (inplace upgrade) - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 48522F67.7080809@sun.com
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Responses Re: Proposal: Multiversion page api (inplace upgrade)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: default client encoding in postgresql.conf
Next
From: ITAGAKI Takahiro
Date:
Subject: pg_stat_statements