BRIN page type identifier

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: BRIN page type identifier
Date: 2014-11-17 15:40:31
Message-ID: 546A16EF.9070005@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The "special" area in a BRIN page looks like this:

> /* special space on all BRIN pages stores a "type" identifier */
> #define BRIN_PAGETYPE_META 0xF091
> #define BRIN_PAGETYPE_REVMAP 0xF092
> #define BRIN_PAGETYPE_REGULAR 0xF093
>...
> typedef struct BrinSpecialSpace
> {
> uint16 flags;
> uint16 type;
> } BrinSpecialSpace;

I believe this is supposed to follow the usual convention that the last
two bytes of a page can be used to identify the page type. SP-GiST uses
0xFF82, while GIN uses values 0x00XX.

However, because the special size is MAXALIGNed, the 'type' field are
not the last 2 bytes on the page, as intended. I'd suggest just adding
"char padding[6]" in BrinSpecialSpace, before 'flags'. That'll waste 4
bytes on 32-bit systems, but that seems acceptable.

Also, the comment in GinPageOpaqueData needs updating:

> /*
> * Page opaque data in an inverted index page.
> *
> * Note: GIN does not include a page ID word as do the other index types.
> * This is OK because the opaque data is only 8 bytes and so can be reliably
> * distinguished by size. Revisit this if the size ever increases.
> * Further note: as of 9.2, SP-GiST also uses 8-byte special space. This is
> * still OK, as long as GIN isn't using all of the high-order bits in its
> * flags word, because that way the flags word cannot match the page ID used
> * by SP-GiST.
> */

BRIN now also uses 8-byte special space. While you're at it, might want
to move that comment somewhere else, as it's really about a convention
among all page types, not just GIN.

- Heikki

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-17 15:46:58 Re: Unintended restart after recovery error
Previous Message Andres Freund 2014-11-17 15:37:39 Re: logical decoding - reading a user catalog table