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 <[EMAIL PROTECTED]> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature