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

From Tom Lane
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 12071.1213373917@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> 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.

I don't have any problem at all with the idea that in-place update isn't
going to support arbitrary changes of parameters, such as modifying the
toast chunk size.  In particular anything that is locked down by
pg_control isn't a problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: default client encoding in postgresql.conf
Next
From: Bruce Momjian
Date:
Subject: Re: Overhauling GUCS