Thread: Page type
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.
bufpage.h:
typedef struct PageHeaderData
{
...uint32 pd_type; /* kind and version */
...
}
#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
#define PageSetType(page, kind, major, minor) \(((PageHeader) (page))->pd_type = \ (((kind) << 16) | ((major) << 12) |
((minor)<< 8)) \)
#define PageSetTypeCurrent (page, kind) PageSetType(page, kind, 7, 3)
#define PageGetKind(page) \((((PageHeader) (page))->pd_type & 0xffff0000) >> 16)
#define PageGetFormat(page) \((((PageHeader) (page))->pd_type & 0x0000ff00) >> 8)
#define PageGetFormatMinor(page) \((((PageHeader) (page))->pd_type & 0x00000f00) >> 8)
#define PageGetFormatMajor(page) \((((PageHeader) (page))->pd_type & 0x0000f000) >> 12)
With most page types this looks like a waste of space (0,05%), which I
hope can be compensated for by greater flexibility in future Postgres
versions. With rtree and gist pd_type replaces a flags field in
OpaqueData (not yet sure about this; will investigate further).
Note, that this or any other kind of version information has to be
implemented at least one release *before* it can be used for the first
time.
Comments? Any chance for this to go into 7.3?
ServusManfred
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
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 <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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I didn't follow the index part completely, but will heap and index pages
> have the version info in the same offset?
Sure, low byte of pd_pagesize.
> Will there be a way to easily identify an index page vs. a heap page.
There already is: heap pages have zero special-space size, indexes
don't.
regards, tom lane