Re: Proposal: Multiversion page api (inplace upgrade) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 200806121743.m5CHhpJ03188@momjian.us
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: Proposal: Multiversion page api (inplace upgrade)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Heikki Linnakangas wrote:
> Zdenek Kotala wrote:
> > 4) Implementation
> > 
> > The main point of implementation is to have several version of 
> > PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct 
> > structure will be handled in special branch (see examples).
> 
> (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.
> 
> Note that you need to handle not only page header changes, but changes 
> to internal representations of different data types, and changes like 
> varvarlen and combocid. Those are things that have happened in the past; 
> in the future, I'm foreseeing changes to the toast header, for example, 
> as there's been a lot of ideas related to toast options compression.

I understand the goal of having good modularity (not having ReadBuffer
modify the page), but I am worried that doing multi-version page
processing in a modular way is going to spread version-specific
information all over the backend code, making is harder to understand.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Overhauling GUCS
Next
From: "Nathan Boley"
Date:
Subject: Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics