BRIN page type identifier
От | Heikki Linnakangas |
---|---|
Тема | BRIN page type identifier |
Дата | |
Msg-id | 546A16EF.9070005@vmware.com обсуждение исходный текст |
Ответы |
Re: BRIN page type identifier
|
Список | 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
В списке pgsql-hackers по дате отправления: