From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG_PAGE_LAYOUT_VERSION 5 - time for change |
Date: | 2008-11-01 20:07:35 |
Message-ID: | 17380.1225570055@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Hmm, you're right. I think it can be made to work by storing the *end*
> offset of each chunk. To find the chunk containing offset X, search for
> the first chunk with end_offset > X.
Yeah, that seems like it would work, and it would disentangle us
altogether from needing a hard-wired chunk size. The only downside is
that it'd be a pain to convert in-place. However, if we are also going
to add identifying information to the toast chunks (like the owning
column's number or datatype), then you could tell whether a toast chunk
had been converted by checking t_natts. So in principle a toast table
could be converted a page at a time. If the converted data didn't fit
you could push one of the chunks out to some new page of the file.
On the whole I like this a lot better than Zdenek's original proposal
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00556.php
which didn't seem to me to solve much of anything.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-11-01 20:16:51 | Re: FAQ_Solaris 1.28 to spanish |
Previous Message | Michael Meskes | 2008-11-01 19:55:37 | gram.y => preproc.y |