Antes en entrar en el tema me parece importante aclarar el término anglosajón Tuning con el que nos referimos a “puesta a punto” de algo.
Para poder entender el rendimiento de PostgresQL y poder realizar una correcta optimización de éste, debemos primero entender cuál es su arquitectura.
Entendiendo la Arquitectura de PostgresQL
Arquitectura Interna
![]() |
Figura 1.0 |
La figura 1.0, muestra la vista general de la arquitectura de PostgresQL, la cual se explica a continuación:
Las aplicaciones cliente pueden comunicarse con el servidor por medio de la librería LIBPQ, las cuál puede considerarse como el canal de comunicación.
Cuando se establece una conexión con el servidor este verifica que por medio del Postmaster si la conexión del cliente es aceptada y si se realiza con un medio de autenticación valido. Si la conexión es válida entonces el Postmaster establece un nuevo servicio de Postgres para el cliente; el cual será encargado de manejar los querys y los comando ejecutados por el cliente. Por cada conexión que acepte el Postmaster se genera un servicio interno de Postgres.
El Postmaster verifica las conexiones por medio de 3 archivos lo cuales permiten especificar la configuración del servidor y son Postgresql.conf pg_hba.conf y pg_ident.conf
El servicio Postgres (backend) se auxilia de la memoria asignada tanto para la data ( PostgresQL Shared Buffer Cache) y la asignada para los registros del log (Write-ahead LOG) para almacenar temporalmente la data que necesita como resultado de las querys y la data ingresada o modificada por el usuario y cuyos registros del WAL no han sido escritos en disco.
Kernel Disc Buffer Cache es la memoria asignada a PostgreSQL
Disco es donde se almacenan los datos y toda la información necesaria para que PostgresQL funcione.
• PostgresQL utiliza un tamaño de página fijo (normalmente 8 kB), (ver figura 2.0) y no permite que las tuplas abarquen varias páginas. Por lo tanto, no es posible almacenar directamente los valores de campo muy grandes. Para superar esta limitación, los valores de campo grandes se comprimen y/o rompen en múltiples filas físicas. Dicha técnica es conocida como TOAST. En el encabezado de fila se coloca el puntero hacia una tabla del tipo TOAST. Y se ocupa en tipos de datos variables. Los datos pueden comprimirse para guardarse y se colocan en tantas filas como el tamaño del dato lo demande.
• El código TOAST se activa sólo cuando un valor de fila (campo) para ser almacenado en una tabla es más ancho que TOAST_TUPLE_THRESHOLD (normalmente de 2 kB). El código TOAST comprime y / o mueve los valores de campo (out-of-line) fuera de línea hasta que el valor de la fila es más corta que TOAST_TUPLE_TARGET.
• Cada tipo de datos TOAST table específica una estrategia por defecto para las columnas de ese tipo de datos, pero la estrategia para una columna de tabla determinada se puede modificar con ALTER TABLE SET STORAGE.
![]() |
Figura 2.0 |
· FREE SPACE MAP (MAPA DE ESPACIO LIBRE): Cada montón y relación de índice, a excepción de los índices hash, tiene un mapa de espacio libre (FSM) para realizar un seguimiento del espacio disponible en la relación. El mapa de espacio libre está organizado como un árbol de páginas FSM. Las páginas FSM del nivel inferior almacenan el espacio libre disponible en cada montón (o índice) de página, usando un byte para representar cada una de estas páginas. El nivel superior agrega información de los niveles inferiores.
· VISIBILITY MAP (MAPA DE VISIBILIDAD): Cada relación de montón tiene un mapa de visibilidad (VM) para realizar un seguimiento de las páginas que sólo contienen tuplas que se saben que son visibles para todas las transacciones activas. Se almacena junto con los datos principales relaciones en una relación separada desprendida, nombrado después del número filenode de la relación, más un sufijo _vm. Tiene que ver con el control de concurrencia MVCC y vacuum. El mapa de visibilidad se limita a almacenar un bit por página montón. Un bit activado significa que todas las tuplas de la página se conocen como visibles para todas las transacciones. Esto significa que la página no contiene ninguna tuplas que necesita ser limpiada (vacuumed).
· INICIALIZACIÓN FORK: Cada tabla unlogged y cada índice en una tabla unlogged, tiene un inicialización. La inicialización es una tabla vacía o el índice del tipo apropiado. Cuando una tabla debe restablecerse para vaciarse debido a un accidente, la inicialización se copia sobre el principal y otros predecesores se borran (se volverán a crear automáticamente si es necesario).
No hay comentarios:
Publicar un comentario