64.6 Database Page Layout

64.6 Database Page Layout

esta seccion ofrece una vision de el formato de pagina usado con las tablas indexadas de posstgreSQL.
las tablas de secuancia y Toast son reformateadas solo como una tabla regular.

en la siguiente explicacion, un byte asume un contenido de 8 bits. en adicion,
el termino "item" se refiere a un valor de dato individual que es almacenado en una pagina.
En una tabla, un "item" es una fila; en un indice, un "item" es un indice de entrada.

Todas las tablas e indices son almacenadas como un arreglo de paginas de tamaño variable
(comunmente 8 kb, aunque una pagina de diferente tamaño puede ser seleccionada cuando
el servidor esta compilando).
En una tabla, todas las paginas son logicamente equivalentes, asi que un item (fila) particular puede
ser almacenada en alguna pagina. En indices, la primer pagina es generalmente reservada como
una metapagina con informacion de control, y puede tener diferentes tipos de paginas dentro del indice,
segun el indice del metodo de acceso.

La tabla 65-2 muestra la disposicion completa de una pagina. hay cinco partes para cada pagina.

Tabla 65-2. dispocision general de pagina
________________________________________________________________________________________
| Item | Descripcion |
|----------------|-----------------------------------------------------------------------|
| PageHeaderData |24 bits de longitud. contiene informacion general acerca de la pagina, |
| |incluyendo apuntadores de espacio libre. |
|----------------|-----------------------------------------------------------------------|
| ItemIdData |Arreglo de (pricipio,alcance) par de apuntadores para los items |
| |actuales. 5 bytes por item. |
|----------------|-----------------------------------------------------------------------|
| Free Space |The unallocader space. Los nuevos apuntadores son alojados desde el |
| |inicio de esta area, nuevos elementos desde el final. |
|----------------|-----------------------------------------------------------------------|
| Items |Los propios items actuales. |
|----------------|-----------------------------------------------------------------------|
|Special space |Acceso a indices de metodos de datos especifcos. Diferentes metodos |
| |almacenan diferentes datos. vacio en tablas ordinarias. |
|________________|_______________________________________________________________________|

Los primeros 24 bytes de estas paginas consisten de una una pagina encabezado (PageHeaderData). ese
formato es detallado en la tabla 65-3. The first field tracks the most recent WAL entry related to this page.
El segundo campo contiene checksum si los datos checksums estan activados. El siguiente es un campo
de 2-byte que contiene bits de bandera. Esto esta seguido por tres campos enteros de 2-bytes (pd_lower, pd_upper y pd_special).
Estos contienen bytes offsets desde la pagina de inicio hasta el inicio del espacio no locaizado. Los siguientes
2 bytes de la pagina encabezado, pd_pagesize_version, almacenan bajo la pagina un indicador del tamaño y una version.
Comenzando con PostgreSQL 8.3 la version es la numero 4; PostgreSQL 8.1 y 8.2 usan la version 3;
PostgreSQL 8.0 usa la version numero 2; PostgreSQL 7.3 y 7.4 usan la version 1; las versiones release usan la
version numero 0. (el formato basico de pagina layout y encabezado no tienen cambios en la mayoria de estas versiones,
pero el layout del heap row headers has.) El tamaño de pagina esta basicamente presente solo como
un cross-check; esto no es soportado mas que por un tamalo de pagina en la instalacion. El ultimo campo
is a hint that shows whether pruning the page is likely to be profitable: it tracks the oldest un-pruned xmax on the page.

Tabla 65-3. PageHeaderData Layout
_________________________________________________________________________________________
| Field | Type | Length | Description |
|--------------------|--------------|--------|--------------------------------------------|
| | | |LSN: Siguiente byte despues del ultimo byte |
|pd_lsn |PageXLogRecPtr| 8 bytes|almacenado xlog para el ultimo cambio a la |
| | | |pagina. |
|--------------------|--------------|--------|--------------------------------------------|
|pd_checksum |unit16 |2 bytes |Pagina checksum |
|--------------------|--------------|--------|--------------------------------------------|
|pd_flags |unit16 |2 bytes |bits bandera |
|--------------------|--------------|--------|--------------------------------------------|
|pd_lower |locationIndex |2 bytes |offset de incio del espacio libre |
|--------------------|--------------|--------|--------------------------------------------|
|pd_upper |locationindex |2 bytes |offset de fin del espacio libre |
|--------------------|--------------|--------|--------------------------------------------|
|pd_special |LocationIndex |2 bytes |offset de inicio de espacio especial |
|--------------------|--------------|--------|--------------------------------------------|
| | | |Pagina de tamaño e informacion de numero de |
|pd_pagesize_version |unit16 |2 bytes |version de layout |
|--------------------|--------------|--------|--------------------------------------------|
| | | |Oldest unpruned XMAX on page |
|pd_prune_xid |TransactionId |4 bytes |o cero si es nula |
|____________________|______________|________|____________________________________________|

todos los detalles pueden ser encontrados en src/include/storage/bufpage.h.

siguiendo la lagina encabezado estan los item identificadores (ItemIdData), estos requieren 4 bytes.
Un item identificador contiene un byte-offset de el inicio de un item, este tamaño en bytes,
y un atrubuto de pocos bits el cual afecta esa interpretacion.
Nuevos items identificadores son alojados como necesarios desde el inicio del espacio
no localizado. El numero de items identificadores presentes pueden ser determinados por lookig at pd_lower,
los cuales increased al alojaiento un nuevo identificador. Porque un item identificador nunca es movido hasta
que este liberado, el indice puede ser usado como un long-term basis to reference an item, even
cuando el item se mueve sobre una pagina al espacio compacto libre. in fact, todos los apuntadores a un item (
ItemPointer, tambien conocido como CTID) creado por PostgreSQL consiste de un numero de pagina y el indice de un
item identificador.

los items se almacenan en espacio allocaded backwards desde el fin del espacio alojable, la estructura exacta
varia dependiendo de que tabla esta contenida. las tablas y secuencias both usan una estructura llamada HeadTupleHeaderData,
described below.

la seccion final es la "Seccion especial" la cual puede contener algun metodo de acceso wishes to store. por ejemplo,
indice b-tree alamacena enlaces a la izquierda y derecha de la pagina siblings, como algun otro dato relevante del indice estructura.
las tablas ordinarias no usan una seccion especial a todo (indicado por la definicion pd_special para igualar el tamaño de pagina).

todas las filas de una tabla son estructuradas de la misma forma. Existe un encabezado de tamaño fijo
(ocupando 23 bytes en la mayoria de las maquinas), seguido por un bitmap opcional nulo, un
campo opcional de objeto ID, y los datos de usuario. el header esta detallado en la tabla 65-4.
los datos de usuario actuales (columnas de una fila) comienzan al principio indicado por
t_hoff, la mayoria de los cuales estan a multiples distancias MAXALIGN por la plataforma. El bitmap nulo esta presente solamente
si el HEAP_HASNULL bit esta definido en t_infomask. Si esta presente, este comienza solo despues de reparar el header y ocupar suficientes
bytes para tener un bit por dato de columna (eso es, bits juntos t_natts). En esta lista de bits, un bit 1 indica not null, un bit 0 es null. cuando
el bitmap no esta presente, todas las columnas estan en not null. el objeto ID esta presente solamente si el bit HEAP_HASOID esta definido en
t_infomask. si esta, este solo aparece antes del limite de t_hoff. any padding needed to make t_hoff a MAXLIGN multiple will appear between the null bitmap
and the null bitmap and the object ID.(this in turn ensures that the object ID es suitably aligned).

Tabla 65-4. HeadTubleHeaderData Layout.

______________________________________________________________________________________________
| Field | Tipo | tamaño | Descripción |
|-----------|------------------|--------|----------------------------------------------------------|
|t_xmin |TransactionId |4 bytes |inserta stamp XID |
|-----------|------------------|--------|----------------------------------------------------------|
|t_xmax |TransactionId |4 bytes |elimina stamp XID |
|-----------|------------------|--------|----------------------------------------------------------|
|t_cid |CommandId |4 bytes |inserta y/o elimina stamp CID (overlays con t_xvac) |
|-----------|------------------|--------|----------------------------------------------------------|
|t_xvac |TransactionId |4 bytes |XID para la operación de vacío mover una versión de fila |
|-----------|------------------|--------|----------------------------------------------------------|
|t_ctid |ID de transacción |6 bytes |TID actual de esta o una versión fila |
|-----------|------------------|--------|----------------------------------------------------------|
|t_infomask2|uint16 |2 bytes |número de atributos, además de varios bits de la bandera |
|-----------|------------------|--------|----------------------------------------------------------|
|t_infomask |uint16 |2 bytes |varios bits de la bandera |
|-----------|------------------|--------|----------------------------------------------------------|
|t_hoff |uint8 |1 bytes |compensar los datos de usuario |
|-----------|------------------|--------|----------------------------------------------------------|

Todos los detalles se pueden encontrar en src / include / acceso / htup_details.h .

Interpretación de los datos reales sólo se puede hacer con la información obtenida de otras tablas, en su mayoría pg_attribute .
Los valores de las claves necesarias para identificar ubicaciones de campo se attlen y attalign . No hay manera de obtener directamente un atributo particular,
excepto los campos de anchura cuando sólo son fijos y no hay valores nulos. Todo esto engaño está envuelto en las funciones heap_getattr , fastgetattr y heap_getsysattr .

Para leer los datos que necesita para examinar cada atributo a su vez. En primer lugar comprobar si el campo es nulo de acuerdo con el mapa de bits nula.
Si es así, pasar a la siguiente. A continuación, asegúrese de que tiene la alineación a la derecha. Si el campo es un campo de ancho fijo, entonces todos los bytes se colocan simplemente.
Si se trata de un campo de longitud variable (attlen = -1), entonces es un poco más complicado. Todos los tipos de datos de longitud variable comparten la estructura común cabecera varlena
estructura , que incluye la longitud total del valor almacenado y algunos bits de la bandera. Dependiendo de las banderas, los datos pueden ser en línea o en un tabla toast;
puede ser comprimido.

INTEGRANTES:
BAUTISTA SAAVEDRA OSCAR ALEXIS
ROBLES CALVO JOSE JUAN