I didn't follow the index part completely, but will heap and index pages have the version info in the same offset? Will there be a way to easily identify an index page vs. a heap page.
--------------------------------------------------------------------------- Tom Lane wrote: > Manfred Koizar <[EMAIL PROTECTED]> writes: > > Having contributed to the need for pg_dump/initdb/restore when > > upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make > > future transitions easier. > > We do need a page version code but I do not want to waste 4 bytes per > page on it. > > I was intending to steal the low order byte of the pd_pagesize field, > thereby restricting page sizes to be multiples of 256 (no big loss). > Extant databases would appear to have page version number zero. > > > #define PKIND_HEAP 0x36ae > > #define PKIND_BTREEMETA 0x696e > > #define PKIND_BTREEINT 0x7552 > > #define PKIND_BTREELEAF 0x0c9c > > #define PKIND_HASH 0xce79 > > #define PKIND_SEQUENCE 0xd863 > > #define PKIND_GISTINT 0x5b52 > > #define PKIND_GISTLEAF 0xde08 > > #define PKIND_RTREEINT 0x6d17 > > #define PKIND_RTREELEAF 0x239e > > This is vast overkill. There might be some value in distinguishing the > different kinds of indexes (although I think you can already do that by > paying attention to the size of the special space; if not, you'd have to > actually look into page zero). We do not need redundant marking of the > type of the individual index page. > > > With rtree and gist pd_type replaces a flags field in > > OpaqueData (not yet sure about this; will investigate further). > > This is not an improvement, only change for the sake of change. > I'd suggest leaving the existing index logic alone. > > I was intending only to mark 7.3 pages with page version 1 (instead of > 0), viewing that as a way of signaling the different header tuple > layout. > > I could also be talked into moving the LP_xxx flags in ItemIds per your > suggestion of awhile back --- the efficiency gain from letting > offset/size be cleanly aligned is probably marginal, but simply letting > hex dumps of pages be more easily readable has some value. And since > we're breaking dump tools already this doesn't seem to have much cost. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
