From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: In-Place upgrade concept |
Date: | 2007-07-04 01:51:59 |
Message-ID: | 16489.1183513919@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I do have an objection though: TOAST data. Even were the bufmgr to be
> provided with a mechanism to find a data type conversion function I
> don't see what it would do about a toasted datum.
Urgh, that *is* a nasty thought :-(
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-04 02:35:31 | Why so many out-of-disk-space failures on buildfarm machines? |
Previous Message | Gregory Stark | 2007-07-04 01:06:55 | Re: Proposal: In-Place upgrade concept |