"Tom Lane" <[EMAIL PROTECTED]> writes:

> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to