> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment