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