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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(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 07:25:18
Message-ID: 48F2F7DE.8010604@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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. And if we have to retoast all values before they're
accessed, per the other thread, then we can just assume that all toast
chunks that we need to random access are of the new size.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-10-13 07:38:19 Re: [PATCH] Extending pg_class info + more flexible TOAST chunk size
Previous Message Heikki Linnakangas 2008-10-13 07:04:48 Re: pg_upgrade: convert on read is dead end