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

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size
Date: 2008-10-13 08:45:14
Message-ID: 48F30A9A.5050804@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2008-10-13 08:53:44 Re: The Axe list
Previous Message Zdenek Kotala 2008-10-13 08:36:28 Re: pg_upgrade: convert on read is dead end