From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Multiversion page api (inplace upgrade) |
Date: | 2008-06-11 15:15:06 |
Message-ID: | 7463.1213197306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> (this won't come as a surprise as we talked about this in PGCon, but) I
> think we should rather convert the page structure to new format in
> ReadBuffer the first time a page is read in. That would keep the changes
> a lot more isolated.
The problem is that ReadBuffer is an extremely low-level environment,
and it's not clear that it's possible (let alone practical) to do a
conversion at that level in every case. In particular it hardly seems
sane to expect ReadBuffer to do tuple content conversion, which is going
to be practically impossible to perform without any catalog accesses.
Another issue is that it might not be possible to update a page for
lack of space. Are we prepared to assume that there will never be a
transformation we need to apply that makes the data bigger? (Likely
counterexample: adding collation info to text values.) In such a
situation an in-place update might be impossible, and that certainly
takes it outside the bounds of what ReadBuffer can be expected to manage.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2008-06-11 15:35:17 | Re: Proposal: Multiversion page api (inplace upgrade) |
Previous Message | Heikki Linnakangas | 2008-06-11 14:59:06 | Re: Proposal: Multiversion page api (inplace upgrade) |