Re: Page type

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(at)aon(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073