Re: 7.2.3?

On Sun, 2002-09-29 at 09:47, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > What would that converter need:
> > [snip]
> > I think that should be enough for converting table files. I'd like to
> > experiment with something like this when I have some free time. Maybe
> > next year...
>
> It's difficult to say anything convincing on this topic without a
> specific conversion requirement in mind.
>
> Localized conversions like 7.3's tuple header change could be done on a
> page-by-page basis as you suggest. (In fact, one reason I insisted on
> putting in a page header version number was to leave the door open for
> such a converter, if someone wants to do one.)
>
> But one likely future format change for user data is combining parent
> and child tables into a single physical table, per recent inheritance
> thread. (I'm not yet convinced that that's feasible or desirable,
> I'm just using it as an example of a possible conversion requirement.)
> You can't very well do that page-by-page; it'd require a completely
> different approach.

I started to think about possible upgrade strategy for this scenario and
came up with a whole new way for the whole storage :

We could extend our current way of 1G split files for inheritance, so
that each inherited table is in its own (set of) physical files which
represent a (set of) 1G segment(s) for the logical file definition of
all parent. This would even work for both single and multiple
inheritance !

In this case the indexes (which enforce the uniquenaess and are required
for RI) would see the thing as a single file and can use plain TIDs. The
process of mapping from TID.PAGENR to actual file will happen below the
level visible to executor. It would also naturally cluster similar
tuples.

Aa an extra bonus migration can be done only by changing system catalogs
and recreating indexes.

It will limit the size of inherited structure to at most 16K different
tables (max unsigned int/pagesize), but I don't think this will be a
real limit anytime soon.

---------------------
Hannu