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-03 22:48:40 |
Message-ID: | 14443.1183502920@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:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-04 00:43:14 | Re: Proposal: In-Place upgrade concept |
Previous Message | Alvaro Herrera | 2007-07-03 22:34:02 | Re: Still recommending daily vacuum... |