Manfred Koizar <mkoi-pg@aon.at> 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
