Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

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

In response to

Responses

Browse pgsql-hackers by date

  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