Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size
Дата
Msg-id 48F30A9A.5050804@sun.com
обсуждение исходный текст
Ответ на Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> The problem what I need to solve is how to handle different TOAST 
>> chunk size which becomes with upgrade. if you insert new record into 
>> TOAST table it will be created on the new page which has different max 
>> chunk size, because it depends on page header size. It means that one 
>> TOAST table will have more chunk size.
>> Use old value from previous version is possible but it could invoke 
>> waste of space in situation when pageheader in a new version is bigger.
>>
>> Another solution is to take first chunk size and say - it is max chunk 
>> size.
> 
> Not all chunks need to be the same size. We do currently require that, 
> but AFAICS it's only because that allows random access to a given offset 
> within a datum. That's of course nice, but I think we could live without 
> it. 

Good point. I think it is good to keep this feature.

> Or try random access with the new toast size first, and if the 
> chunks turn out to be different size, fall back to reading all chunks 
> sequentially. 

I think it is not necessary to read it sequentially, only you need to recompute 
new position.
    Zdenek


-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: Re: pg_upgrade: convert on read is dead end
Следующее
От: Markus Wanner
Дата:
Сообщение: Re: The Axe list