From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: BRIN page type identifier |
Date: | 2015-03-09 22:35:05 |
Message-ID: | 20150309223505.GT3291@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> 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.
Ouch. You're right. I don't understand why you suggest to use 6 bytes,
though -- that would make the struct size be 10 bytes, which maxaligns
to 16, and so we're back where we started. Using 4 bytes does the
trick.
I wonder if this is permissible and whether it will do the right thing
on 32-bit systems:
/*
* Special area of BRIN pages.
*
* We add some padding bytes to ensure that 'type' ends up in the last two
* bytes of the page, for consumption by pg_filedump and similar utilities.
* (Special space is MAXALIGN'ed).
*/
typedef struct BrinSpecialSpace
{
char padding[MAXALIGN(1) - 2 * sizeof(uint16)];
uint16 flags;
uint16 type;
} BrinSpecialSpace;
It's a bit ugly, but it seems to work for me on x86-64 ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-03-09 22:36:43 | Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement() |
Previous Message | Andreas Karlsson | 2015-03-09 22:24:34 | Re: New functions |