Message-ID: <546A16EF.9070005@vmware.com>
Date: Mon, 17 Nov 2014 17:40:31 +0200
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: Alvaro Herrera <alvherre@2ndquadrant.com>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: BRIN page type identifier
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers