On Tue, Jul 03, 2007 at 09:51:59PM -0400, Tom Lane wrote:
> Out-of-line datums aren't the only issue, either: consider inline
> compressed datums. A data representation change, even one that is known
> not to increase the ordinary uncompressed size of the datum, could
> easily render it slightly less compressible, resulting in a risk that
> the tuple doesn't fit on the page anymore. It hardly seems practical
> (maybe not even possible) to guarantee that this cannot happen.
Does the converted page have to fit into a single page? It's a bit of a
corner-case, there's slack on every page. Wouldn't it be possible to
replace an oversize tuple with a pointer to a new tuple on a new page
(indexes are the problem here).
> So maybe we are up against the conclusion that in-place updates cannot
> support datatype representation changes, at least not for toastable
> datatypes. We could still handle 'em by the expedient suggested
> upthread for user-defined types, ie the "new representation" is treated
> as a whole new type. That's not terribly appetizing though; I had
> expected we could be more efficient for the case of changes in built-in
> types.
Well, it seems to me 99% of cases can be handled easily, we just might
have to have a backup method for the cases where the simple cases
doesn't work...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.