Bruce Momjian napsal(a):
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.

I don't think so. Page already contains page version information inside and currently we have macros like PageSetLSN. Caller needn't know nothing about PageHeader representation. It is responsibility of page API to correctly handle multi version.

The same we can use for tuple access. It is more complicated but I think it is possible. Currently we several macros (e.g. HeapTupleGetOid) which works on TupleData structure. "Only" what we need is extend this API as well.

I think in final we will get more readable code.

                Zdenek


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to