"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> 2. Page format conversion is WAL-logged as a complete page replacement
>
>> It seems we get that for free. By definition any modification to a page after
>> conversion will be the first record for that page since a checkpoint.
>
> No, I don't think so. Consider a page that's been sucked in for just a
> SELECT. Or did you plan to pay the page conversion cost over and over
> again until it's finally modified? Anyway the whole idea fails if the
> first mod that needs to be made is just a hint-bit update.
Ah, true, it would have to dirty the page and that means putting an LSN in and
that means needing a WAL record to point it to. But the actual record is
almost irrelevant as any record will cause the full page to be attached.
>> Hm, perhaps we could do it by doing as much of the work up-front as possible.
>> Requiring datatypes to define a function in pg_proc to do the conversion and
>> require that it be a function which can stand on its own without catalog
>> lookups or other facilities.
>
> I don't think you quite got the point of "no catalog lookups". That
> includes not looking up pg_type or pg_proc entries.
ISTM that it's really just not looking up pg_type or pg_proc entries *from
within the low level storage code* that's evil. If they're all sucked in on
backend startup and restricted by policy to not be able to do anything fancy
themselves then I don't see your objection.
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. Obviously bufmgr can't fiddle with it, and if
it leaves it for pg_detoast_datum then even if there were some way for
pg_detoast_datum to know whether it's an old format datum or a new format one
there's no way for it replace the TOAST datum on disk with the new one.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
