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
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 |