Re: Proposal: Multiversion page api (inplace upgrade)

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: Proposal: Multiversion page api (inplace upgrade)
Дата
Msg-id 48522F67.7080809@sun.com
обсуждение исходный текст
Ответ на Re: Proposal: Multiversion page api (inplace upgrade)  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Ответы Re: Proposal: Multiversion page api (inplace upgrade)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: default client encoding in postgresql.conf
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: pg_stat_statements