Está en la página 1de 113

Introducci´ on a PostgreSQL

Ing. Pedro Mu˜ noz del Rio pmunoz@gmail.com Lima, Per´ u

Introducci´ on
PostgreSQL es un gestor de bases de datos relacionales que empez´ o como un proyecto de la universidad de Berkeley en California y su historia data desde los comienzos de las bases relacionales. Posee funcionalidades de corte empresarial como funciones para crear vistas, funciones agregadas para aplicar sobre las vistas entre otras. Tiene la capacidad de aceptar grandes cantidades de datos, como tablas con decenas de millones de registros sin mayor problema. Adem´ as de un gestor de bases de datos, PostgreSQL es una plataforma para aplicaciones y permite escribir procedimientos almacenados y funciones en diversos lenguajes como SQL, Python y Java entre otros, agregando los m´ odulos necesarios en el caso de los u ´ltimos. Conectarse a un web service a trav´ es de Python, usar funciones estad´ ısticas de R y consultar los resultados con SQL es posible mediante PostgreSQL. Adem´ as, se pueden definir tipos propios de datos, instalar f´ acilmente extensiones mediante una sola instrucci´ on SQL y administrarlas con sencillez. Y como si fuera poco, Postgresql es multiplataforma, por lo cu´ al puede ser implementado tanto en Linux, BSD como Windows e incluso Mac OS, con binarios disponibles si no se desea compilar postgresql. Los lenguajes de programaci´ on m´ as populares tienen librer´ ıas que les permiten comunicarse con Postgresql y hacer consultas, entre los m´ as conocidos PHP, Python, Ruby, Java, .Net, Perl entre otros. Hoy en d´ ıa, PostgreSQL es una de las alternativas m´ as relevantes en el campo de las Bases de Datos relacionales, de c´ odigo abierto y utilizada por empresas de todo tama˜ no a nivel mundial.

i

´ Indice
Introducci´ on 1. Arquitectura del Sistema 1.1. Breve historia . . . . . . . . . . . . . . . . . 1.2. ¿Quienes utilizan PostgreSQL? . . . . . . . 1.2.1. Internacionales . . . . . . . . . . . . 1.3. Resumen de la Arquitectura . . . . . . . . . 1.3.1. Gesti´ on de la data . . . . . . . . . . 1.3.2. El procesamiento de una consulta . . 1.4. Multi-Version Concurrency Control (MVCC) 1.5. Write-Ahead Logging . . . . . . . . . . . . . 1.6. Objetos m´ as utilizados en PostgreSQL . . . 1.7. Nuevas funcionalidades en PostgreSQL 9.2 . 1.8. Limitaciones . . . . . . . . . . . . . . . . . . 1.9. Instalaci´ on . . . . . . . . . . . . . . . . . . . 2. Administraci´ on 2.1. Configuraci´ on de Postgresql . . . . . . . . 2.2. Creando Bases de Datos . . . . . . . . . . 2.2.1. Comando createdb . . . . . . . . . 2.2.2. Creando una base de datos plantilla 2.2.3. Eliminar una Base de Datos . . . . 2.3. Creando Esquemas . . . . . . . . . . . . . 2.3.1. Permisos . . . . . . . . . . . . . . . 2.3.2. Eliminar esquemas . . . . . . . . . 2.4. Ruta de B´ usqueda de Esquemas . . . . . . 2.4.1. Utilizaci´ on de los esquemas . . . . 2.5. Roles . . . . . . . . . . . . . . . . . . . . . 2.5.1. Crear un usuario . . . . . . . . . . 2.5.2. Atributos de los roles . . . . . . . . 2.6. Grupos . . . . . . . . . . . . . . . . . . . . 2.7. Control de Acceso . . . . . . . . . . . . . .

I

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

1 1 1 1 3 3 5 5 6 6 7 7 7 11 11 14 15 16 17 18 21 24 25 27 27 29 31 32 36 38 38 40 41 41

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

3. Transacciones y concurrencia 3.1. Definici´ on de Transacci´ on . . . . . . . . . . 3.1.1. Savepoints . . . . . . . . . . . . . . . 3.2. Niveles de Aislamiento de las Transacciones 3.2.1. Detalle de los niveles de aislamiento .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

ii

. . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . . 4. .2. . . . . . . Diferencias entre MVCC y Bloqueo . . . . . . . . . . . . 4. . . .4.1. UPDATES . . . . . . . . . 4.5. . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . Efectos del cache de la BD . . . . . . . . . . . . . Memoria para el cache de la Base de Datos . .2. . . . . . .1. . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . 5. .3. . . . . Descripci´ on del Control de Concurrencia 3. . . . . . . . . . . . . . 50 50 51 51 52 54 54 55 55 55 56 56 56 56 57 57 59 59 59 60 61 62 63 68 68 69 71 71 72 73 74 74 75 76 79 79 80 83 87 91 103 103 103 103 104 105 4. . .3.3. . . Ajustes de rendimiento 4. . . . . . . 4. Ordenamiento de Joins . . . . . . . . . . . Cache de la Base de Datos . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . Optimizando las consultas para la data en cache 5. . . . . . postgresql. .2. . . . . . . . Explain y Explain Analyze . . . . . . . . . . 3. . . . . . . . . . . . . . effective cache size . . . . . . . . . . . . .3. . .5.6. . . . . . .4. . . . . . . . . . .1. . . . 4. . . . . . . . . . . . . . . . . . . . . . . . Journaling .2.conf . . . . . .2. . . . . . . . . . . 5. . . . . . . . . . . . . . . . .5. .1. . . . . . . . . Configuraci´ on (postgresql. . . . . . . .2. . . . . . . . . . . . . . 4. . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. Data de ejemplo . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . Armando conjuntos de registros .2. Sistemas de archivos . . . . . . . . . . . . . . . . . 4. . . . . . . . . . . . .2. . . .4. . . . . .1. . Discos . . . . .7. . 4. . . .5. . . . . . . . . 5. . Configuraci´ on del S. . . . . . . . . . .5. . . . . . 4. . . . BSD . . . . . . . 5. . . Efecto de la cache . . . . . . . . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. Configuraci´ on de Hardware . . . 3. .4.6. . . . . .conf . . . . . . . . . . . . . . . . . . . . . . . . . Procesando los nodos . . 5. . . ´ Indices . . . . . . Ejemplo MVCC . . . . . . . . . . . . . . . . . . . . Par´ ametros para el planeamiento de consultas . . . . . 4. . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . .2. . . . . . . . . 5. . . . . . . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . Tips para optimizar SQL . . . . . . . . . . . . 4. . . . . . . . Las consultas y la cache . . . . . . . . . . . . . . . . . . . . .4. . 5. . . . . . . . .5. . . . . . . . . . . . . . . . 4. . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . 5. . . .5. . . . . . . . . . . . . . Memoria . 5. . . .1. . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . CPU . . . . . . .2. . .2. . . . . . . .4. . . .3. . . .1. . . .6. . . . . . . . . . . .3. . . . . . . . . . . . 5. . . . . . . . . . . . . . 3. . . . . .5. . . . . . . . . . . .4.O. . . . . . de . . Comprobar la equivalencia de un query . . . . . . . . . . . . . . . . . . . .conf) . . . . . . . . . 4. . . . EXPLAIN ANALYZE gr´ afico . . . 5. . . . . . . Sistemas de archivos de Linux . . . . . . . . . . . . . .2. . . .1. . . . . . . . . . . . . Optimizaci´ on de consultas . Timing . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . DELETE . . . . . . . . . . Configuraci´ on del sistema de archivos en Linux 4. . .1. . . Configuraci´ on de logs . . .1. . . . . . . . . . . . . 5. . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . 4. 4. . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . .5. . datos . . . . . 4. . Ajustes de rendimiento II: Optimizaci´ on de las Bases 5. .1. . . . . . . . . Joins . . . . . . . . . . . . . . . . . .5. . .4. . . . . . Estructura del plan de la consulta . . . . . work mem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unidades de memoria en postgresql. . . . . . .2. .2. . . . . . .3. . . . . . . . . . . . . . . . 5. . . . . 5. . . . . . . . . . . . . Costo de computaci´ on . . . . . 5. . . . . . . . . Hdparm . . . . . . . . . . . . . . . . . . . . . . . .3. . Configuraci´ on de un nuevo servidor . . . . . 4. . . . .2. . . . . . . . . . . . . . . .4. . .

. . . 8. . . . . . . . . . . . . . 8. . . . . . . . . . 7. . . . . . . . . .3. . . . . Extensiones Comunes . . . . . . Activar PgPool II . . . . . .3. . . .3. . . 9. . . 9. . .2. . . . . . . . . . . . . . . . . . . .2.2. . . . . . . . . . . . . .2. . . . . . .3. . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . Configuraci´ on de PgPool II . . . . . 7. . . . . . . .2. . . . . . . . . 7. . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . .3. . . . . . .8. . . .6. . . . . . . . 7. . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . Instalar PgPool II . . . . . . . . . . . . . . . .2. . . . . . . . . . . . .7.3. . . 154 10. . . . . . . El pool de conexiones . . . . . Utilizar reglas de partici´ on . . . . . .1. . . Crear las particiones . . . . . . . . . . . . . . . .3. .1. . . . . . . . . . . . . . . . . . Funciones Trigger . . . . . . . . . . . . . . . Particionado de tablas 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . .3. . . . .6. . . . . . . . .1. . . . . . Funciones en PL/Python . . . . . . . . . . . . . . . Configuraci´ on de Particionado . . . . . . . . . . . .3. . . . . . 7. . . 9. . . . . . . . . .4. . Pooling de conexiones 8. . . . . . . . . . . . . . . . . . . . . . . . .4. . .1. . . . . . . . . . . . Lenguajes Procedurales 9. . . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . Control de flujo . . . . . . . . . . . . . . Operadores . 8.4. . . . . . . . . . . .1. . . . . . . . . . .2. . . . . 8. . . . Ejemplo de Python . . . .3. . . . . . . . . . 8. . . 8. . . . . . Conceptos de replicaci´ on . . . . . . . . . . . M´ etodos de Particionado . . . . . . . . . . . . . . . . . . . . . . . . . . Instalaci´ on de PgBouncer . Funciones . . . . . . . . . .Extensiones y contrib 154 10. . . . . . .4. . . . . . . . . . . . . . . . . 9. . . . . . . . Colecciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Migraci´ on de la data . . . . . Funciones SQL . . 8. . . . . . . .4.3. . .1. . . 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3. . . . . . . . . 6. . .2. .2. 107 107 107 108 111 111 112 112 113 115 118 119 120 125 125 125 126 126 126 127 127 130 130 130 131 131 131 133 133 135 139 139 140 144 144 145 147 148 150 152 152 . . . . . . 7.3. . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . 7. . . . Conectarse a PgPool II . . . . . . . . . . . . .5. . . .1. . . . . . .3. . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . . 9. . . . 9. . . . . . . 9. . . . 7. . . Aspectos b´ asicos de Python 9. 155 iv . . . . . . . . .4. . . . . . . . . . . . . . . . . . .4. . . . . . . . .4. .1. . . . . . . . . . . Redirigir los INSERT a las particiones 7. Trigger para los Updates . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . Errores al particionar . . . . . . . . . . . . .4. . . . Estructura de una funci´ on . . . . . . . . . . . . . . .2. . . . . . . . 7. . . . Alta disponibilidad y replicaci´ on 6. . Funci´ on python b´ asica . . . . . . . . . . .3. . . . . . . . . . . . . . . Replicaci´ on . . . . . . Ventajas de las particiones . . Particionado . . . . . . . . . . . 10. . . . . . . . . . . . . . . . . . PgPool II . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . Crear nuevas particiones . . . . . . .4. 6. . . . . . PgBouncer . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . Configurar PgBouncer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. . . . . . . . . . . . . . . . . . Funciones PL/pgSQL . . . . . . . . . . . . . Preparar los nodos de bases de datos 8. . . . . . . . . . . . . .5. . . . 8. . . . . Configurar una r´ eplica . . . 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . Tipos b´ asicos . . . . . . . . .7. . . . . . . . . . . .2. . 8. . . 9. . . . Instalar Extensiones . . . .

. . . . . . . . . Procesamiento de una consulta [4] Pantalla principal de Pgadmin3 . . . . . . .2. . . .1. . . . ´ Indices . . . . . . . . . . . .Lista de Gr´ aficos 1. . . . . . . . . . 1.4. . . . . 1. . 3 3 4 5 8 20 2. . . . .3. . . . . . . . . . . . . 1. . . . . . . . . . . . . Arquitectura de PostgreSQL . . EXPLAIN ANALYZE gr´ afico en PgAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura del disco . . . . . . .1. . . . . . . . Asignaci´ on de privilegios en Pgadmin3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . .1. . 1. . . . . . . . . . . 5. . . 105 v . . . .

luego de a˜ nos de desarrollo en la academia. Berkeley) por un profesor llamado Michael Stonebraker en 1986.S.S. como un sucesor de Ingres.2. Breve historia PostgreSQL. fue creada en la UCB (Universidad de California. En 1996. General Services Administration U. etc. Agency for International Development U. Centers For Disease Control and Prevention U. Department of Labor U. a PostgreSQL. trabajando varios a˜ nos hasta liberar la primera versi´ on 6. un equipo de desarrolladores fuera de Berkeley decide liberar el proyecto y hacerse cargo de sus desarrollo. se fueron agregando nuevas funcionalidades como control de la concurrencia. Desde el inicio fue un gestor de base de datos conocido por su estabilidad y con la ayuda de cientos de desarrolladores a nivel mundial.S.S. nuevos tipos de datos. ¿Quienes utilizan PostgreSQL? En el Per´ u y el mundo hay gran cantidad de empresas e instituciones que han confiado uno de sus activos m´ as valiosos.S. a continuaci´ on algunos ejemplos: 1. State Department IMDB.1. 1. mayor perfomance.0 en 1997.1.originalmente llamada Postgres.Cap´ ıtulo 1 Arquitectura del Sistema 1. un motor propiedad de Computer Associates y con el objetivo de avanzar el estado del arte en bases de datos relacionales. The Internet Movie Database 1 .2.com. Internacionales U. su informaci´ on.

Macworld Sun Microsystems Red Hat Apple Fujitsu Cisco Skype 2 .

PostgreSQL almacena una copia invisible hasta que ejecuta VACUUM y se libera de toda la data sobrante. El Storage Manager (Gestor de almacenamiento) es responsable de la gesti´ on del almacenamiento de los datos. controlar todos los trabajos del back-end incluido la administraci´ on del buffer. las cuales se guardan en diferentes posiciones f´ ısicas del disco.1. se obtiene del disco. el “Postmaster” que es el responsable de aceptar las comunicaciones con el cliente.3. se extrae del disco para pasarla a la RAM. si se dispersan por el disco. bloqueos y control de la consistencia de la informaci´ on. y al escribir se transfiere de la RAM al disco. Gesti´ on de la data La data en todo Gestor de Bases de Datos se guarda en bloques de disco llamados “p´ aginas” cuyo tama˜ no var´ ıa entre 8KB y 32KB. archivos.1. autentificar y dar acceso. 3 . En el nivel m´ as alto sigue un esquema cliente-servidor mientras que en el acceso a datos utiliza un esquema por capas. Toda operaci´ on hace que PostgreSQL agregue data.1: Arquitectura de PostgreSQL El m´ odulo Libpq es el encardado de gestionar las comunicaciones entre el cliente y el postmaster (servicio de PostgreSQL en el servidor). esta es utilizada para consultas. en caso no ser as´ ı. Cuando se guarda la data en disco. Cuando se elimina un registro o se modifica. [4] 1. El servidor esta compuesto por 2 grandes m´ odulos. Gr´ afico 1. Resumen de la Arquitectura PostgreSQL tiene una arquitectura que incluye diversos m´ odulos que interactuan entre si. eso significa un solo proceso cliente por conexi´ on. causan menor rendimiento de la base de datos. En PostgreSQL cuando se realizan operaciones de lectura y/o escritura primero se consulta al Buffer (RAM) si contiene la p´ agina. Al leer la data. PostgreSQL trabaja bajo el concepto de “process per user”.3. El “Postgres” se encarga de administrar los querys y comandos enviados por el cliente.

Los ´ ındices representan un gran aumento en el rendimiento de un gestor de base de datos pero consumen espacio de disco por cada ´ ındice que se cree. contienen una secci´ on de data y un puntero a la localizaci´ on del siguiente nodo. pero al buscar en un campo cuyos datos no est´ an ordenados el tiempo de b´ usqueda escala junto con el tama˜ no de la data. Gr´ afico 1.Gr´ afico 1. Estos bloques est´ an estructurados como listas enlazadas.2: Estructura del disco ´ Indices En los discos la data se almacena en bloques de datos llamados p´ aginas. Al crear un ´ ındice en una tabla se crea otra estructura de datos que contiene el valor ordenado del campo y apunta al registro que lo contiene. Es recomendable crear ´ ındices sobre datos que se repitan lo menos posible entre si. solo debe ser utilizado con ese fin. estos bloques son accedidos por entero (operaci´ on at´ omica). Debido a que los registros se buscan por campos. Debido a su capacidad de disminuir el tiempo de b´ usqueda en grandes tablas. Un ´ ındice es un “archivo” donde esta parte de la data y estructura de una tabla con las “search key” de b´ usqueda. buscar en un conjunto de campos es necesario para encontrar los registros que se buscan en una consulta.3: ´ Indices 4 .

etc. por eso es importante escribir bien las consultas.3. update. A continuaci´ on se analiza que lo escrito sea sint´ acticamente correcto y se descompone por token la consulta para pasarla a la estructura que le corresponde (select. El m´ odulo Traffic Cop contiene al controlador principal del proceso del PostgreSQL. etc).1.4: Procesamiento de una consulta [4] El cliente (libpq) se comunica con el servicio del “postmaster” para pasarle una cadena de texto con la consulta.insert. El procesamiento de una consulta Gr´ afico 1. Las consultas complejas pasan al Rewriter (select. se pasan al Utility Commands. El parser transforma la consulta en una serie de instrucciones que la base de datos puede interpretar.). Executor y commands functions. grant. las que no. en general 5 .2. adem´ as se encarga de las comunicaciones entre el Parser. Optimizer.

Multi-Version Concurrency Control (MVCC) Una decisi´ on de dise˜ no importante que se debe tomar en toda BD es como gestionar la interacci´ on de m´ ultiples clientes con la misma data. Mediante el control de concurrencia el gestor permite que muchos usuarios puedan acceder a la misma data al mismo tiempo. las transacciones ven una imagen de la data al momento de empezar (para eso la data se versiona con un timestamp). esto protege la transacci´ on de inconsistencia de data cuando llegan varias operaciones de Lectura/escritura sobre el mismo registro. Bajo el MVCC. Las transacciones deben cumplir el criterio ACID: A tomicity: todas las acciones en la transacci´ on se cumplen o no se cumple ninguna. esto es. El m´ odulo “planner” es el encargado de generar el “plan de ejecuci´ on”. Esto sirve para que en caso de un desastre. Write-Ahead Logging Es el m´ etodo est´ andar en los gestores de bases de datos para asegurar la integridad de la data.5. C onsistency: la transacci´ on solo termina si la data es consistente. El concepto central de WAL es que los cambios a los archivos de data (donde las tablas y los ´ ındices residen) solo deben ser escritos despu´ es que los cambios han sido registrados. despu´ es de que los registros de logs describiendo los cambios se hayan guardado de forma permanente. Cada proceso de usuario ejecuta transacciones las que a su vez pueden contener una o m´ as operaciones. La nueva data no es visible para otras transacciones hasta que no termina la actual transacci´ on y es enviada (committed) a la base de datos. [4] 1. Las alternativas son tres: minimal (opci´ on por defecto). D urability: cuando la transacci´ on termina el resultado de la misma permanece. vacuum. etc). create. PostgreSQL utiliza un enfoque llamado Multiversion Concurrency Control (control multiversi´ on de la concurrencia) el cu´ al es tambi´ en utilizado en otras Bds como Oracle. maneja mediante formulas matem´ aticas avanzadas la forma de b´ usqueda de datos y la forma de resolver las relaciones entre tablas. El par´ ametro wal level de postgresql.conf determina cuanta informaci´ on es registrada en el WAL. archive y hot standby. esto es estimar la mejor v´ ıa para resolver el query.4. La data no se modifica o elimina. se pueda recuperar la Bd utilizando el log del servidor. la implementaci´ on de concurrencia de PostgreSQL. 1. Luego que el planner calcula la forma m´ as eficiente de ejecutar la consulta se la pasa al “Executor” que la lleva a cabo.consulta simples (alter. solo se agregan nuevos registros y los antiguos pasan a ser invisibles. I solation: la transacci´ on es independiente de otras transacciones. 6 .

Tablas. Nuevas funcionalidades en PostgreSQL 9. en postgresql se puede hacer consultas fuentes externa de data ya sea que esa fuente sea otra BD relacional. Sequence. 7 . Es sobre todo usar para instalar m´ odulos adicionales.7.En el nivel minimal. una Bd NoSql. son los disparadores de acciones al detectar cambios en la data. Postgresql permite que se gestionen de forma independiente. no se registran algunas operaciones como CREATE TABLE AS o CREATE INDEX pero este nivel no guarda suficiente informaci´ on como para reconstruir la data de la BD desde el WAL. Cast. Data externa. En PostgreSQL los usuarios pueden crear sus propias funciones de conversi´ on. tipos. Base de datos. indices en una sola unidad para mayor mantenibilidad. lo que significa que se pueden mover las bases de datos a otras particiones o discos con pocos comandos. La diferencia entre ambos es que hot standby no solo registra todos los cambios en la data sino adem´ as las transacciones as´ ı sea de solo lectura 1. Se crean autom´ aticamente cuando se define una columna serial. Extensiones. se utilizan para abstraer las consultas y en PostgreSQL adem´ as pueden ser actualizadas. Cada base de datos puede tener diferentes esquemas. y son los contenedores l´ ogicos de tablas y otros objetos. Vistas. Objetos m´ as utilizados en PostgreSQL El servidor PostgreSQL tambi´ en conocido como servidor o demonio. Triggers. casts. en PostgreSQL se pueden definir por el usuario. Tablespace. Esquemas.2 Algunas de las nuevas funcionalidades de Postgresql 9. agrupan funciones. etc.2 son: [3] Acelerar la consulta de columnas pertenecientes a un index. cada servidor puede tener varias bases de datos. controlan los n´ umeros autoincrementales en las definiciones de las tablas. Para poder llevar a cabo replicaci´ on se necesita utilizar los niveles archive o hot standby. se puede tener m´ as de uno en un servidor siempre y cuando utilicen diferentes puertos o ips y almacenen su data en ubicaciones diferentes. 1. permite convertir de un tipo a otro y es soportado por funciones que realmente hacen la conversi´ on. un archivo plano. un web service. son la principal herramienta de toda base de datos.6. es la localizaci´ on f´ ısica donde la data es almacenada. son funciones simb´ olicas que tienen el respaldo de una funci´ on. Funciones. en Postgresql pueden retornar un solo valor o un set de registros. son parte del est´ andar ANSI-SQL. Operador.

M´ as opciones para ALTER TABLE.Mejoras en el ordenamiento que optimizan operaciones de ordenamiento en memoria hasta un 20 %.2 de PostgreSQL llevamos a cabo los siguientes pasos: Instalar las librer´ ıas requeridas • sudo apt-get install libpq-dev Agregar el repositorio donde est´ a ubicado PostgreSQL 9. Las funciones SQL pueden referirse a los argumentos por nombre y no por n´ umero. Mejoras en el planeamiento de consultas. • sudo add-apt-repository ppa:pitti/postgresql Actualizar la lista de paquetes disponibles: • sudo apt-get update Instalar el servidor • sudo apt-get install postgresql-9.2 (no est´ a a´ un en los repositorios oficiales). Replicaci´ on en cascada ahora soporta streaming de un esclavo a otro esclavo. M´ as opciones para crear y restaurar backups. Instalaci´ on Para instalar en Ubuntu la versi´ on 9. aunque ese es un problema que se est´ a solucionando con el tiempo. 1. ALTER TABLE IF EXISTS sintaxis para hacer cambios en tablas. no es aplicable para ser embebida como SQLite o Firebird. El tipo JSON como tipo nativo de Postgresql. Limitaciones PostgreSQL por su naturaleza de BD para servidores. 8 . La posibilidad de crear funciones en javascript mediante plv8js. en muchos hostings por uno u otro motivo no est´ a presente PostgreSQL. • sudo su postgres -c psql template1 Cambiar la contrase˜ na del usuario postgres.9.2 Poner a punto el servidor: Ingresar en el template1 de Postgresql para cambiar la contrase˜ na del usuario por defecto. Adem´ as. 1.8.

• \q Eliminamos la contrase˜ na del usuario postgres en el sistema • sudo passwd -d postgres Se utiliza su para cambiar el password del usuario postgres • sudo su postgres -c passwd Se crea el usuario “pedro” con el usuario del servidor postgres • sudo -u postgres createuser -D -A -P pedro Crear la DB • sudo -u postgres createdb -O pedro Bd prueba Para instalar Pgadmin: sudo apt-add-repository ppa:voronov84/andreyv sudo apt-get update sudo apt-get install pgadmin3 Gr´ afico 1. Salimos del cliente psql.• postgres=# ALTER USER postgres WITH PASSWORD ’qwerty’.5: Pantalla principal de Pgadmin3 9 .

Para habilitarlo se debe agregar en postgresql.log min duration = ’1s’ as de un segundo reEsta configuraci´ on va a ejecutar auto explain en toda consulta que dure m´ gistr´ andola con un plan EXPLAIN completo.Auto Explain Otra opci´ on muy utilizada despu´ es de la versi´ on 8. 10 .conf los siguientes par´ ametros y reiniciar el servidor: shared preload libraries = ’auto explain’ custom variable classes = ’auto explain’ auto explain.4 de PostgreSQL es el m´ odulo auto explain que permite analizar la duraci´ on de una consultada viendo su plan EXPLAIN asociado.

Ejercicios: 1. apellidop. 4. Crear la tabla Persona de propiedad del usuario “usuario curso” con los siguientes campos: 5. apellidom. Instalar el servidor Postgresql. 2. Crear un usuario llamado “usuario curso”. nombre. 6. 11 . Insertar el nombre y apellidos de tres alumnos en la tabla. Crear una base de datos llamada Base curso. 3.

12 . Una forma sencilla de ver las configuraciones en postgresql. etc. la localizaci´ on f´ ısica de las bases de datos. pg hba.conf : El principal archivo de configuraci´ on de postgresql. por ejemplo la siguiente consulta devuelve los valores de seis par´ ametros de postgresql. controla configuraciones generales como la cantidad de memoria RAM a utilizar.conf es consultar la tabla pg settings. Configuraci´ on de Postgresql Los archivos utilizados para configurar postgresql son tres: [3] postgresql.Cap´ ıtulo 2 Administraci´ on 2.1.conf. setting FROM pg_settings WHERE category = ’File Locations’. pg ident.conf : Es el archivo que mapea los usuarios del SO con los usuarios del servidor Para conocer donde est´ an localizados en el sistema. las ips a las que escucha postgresql.conf : controla la seguridad. se puede utilizar un superusuario del servidor para ejecutar la siguiente consulta: $ sudo su postgres -c “psql -d Bd prueba” Y luego: SELECT name. que Ips o grupos de Ips est´ an permitidos de conectarse y el esquema de autenticaci´ on esperado. gestiona el acceso al servidor indicando que usuarios pueden acceder a que BD. la configuraci´ on de los logs.

2. lo cu´ al elimina a su vez todos sus objetos como tablas. show all. ´ ındices. La primera base de datos en ser creada al instalarse PostgreSQL es postgres y luego template0 y template1 que son plantillas de bases de datos desde las cu´ ales se copian las nuevas bases en ser creadas. por lo que se recomienda ser muy prudente con las plantillas. El due˜ no de la Bd ser´ a el usuario en el sistema y la BD ser´ a una copia de template1. 2. reset_val FROM pg_settings WHERE name in (’listen_addresses’. Por ejemplo: CREATE DATABASE nombre_db OWNER usuario_curso. Es potestad del creador de una Base de Datos eliminarla posteriormente.SELECT name. por ejemplo: show maintenance_work_mem. Si se desea crear una base de datos con otro due˜ no fuera del usuario que la est´ a creando. setting. Solo el superusuario puede crear una base de datos para otro usuario. 13 .’effective_cache_size’. funciones. boot_val. show work_mem.name. se agrega el par´ ametro OWNER.’max_connections’. context. etc as´ ı tengan otros due˜ nos. ’maintenance_work_mem’) ORDER BY context. ’work_mem’. Todo cambio que se haga en template1 se replicar´ a en toda nueva Base de datos. Creando Bases de Datos La forma m´ as sencilla de crear una base de datos es ingresando a un cliente (como psql) y utilizando el comando: CREATE DATABASE mi_bd. Tambi´ en se puede utilizar el comando show para ver cada par´ ametro de configuraci´ on por separado con su valor respectivo.’shared_buffers’.

Mediante par´ ametros se puede utilizar createdb de forma m´ as vers´ atil. Creando una base de datos plantilla Una base de datos de plantilla (Template DB) es una base de datos que sirve de plantilla para crear otras bases de datos. 14 .2.2. template0 nunca debe ser modificada. Por ejemplo: createdb -U postgres -O usuario curso nueva bd Va a crear una base de datos llamada nueva bd mediante el usuario postgres y va a ser propiedad de usuario curso. A diferencia de la segunda.1. con -O se indica el owner de base de datos creada. se pueden utilizar otras bases de datos como plantillas. se replicar´ an en todas las nuevas bases que se creen teniendo a template1 como plantilla. que contiene el mismo contenido inicial que template1. Para crear una copia de template0 se ejecuta: CREATE DATABASE dbname TEMPLATE template0. Comando createdb Como conveniencia se puede utilizar el comando createdb desde la terminal: createdb nombre db Lo que hace createdb es conectarse a la base de datos postgres y ejecuta CREATE DATABASE utilizando el usuario del sistema desde el cu´ al se le ejecuta. con la limitante de que ninguna otra sesi´ on puede estar conectada a la base de datos fuente mientras es copiada. template0. se crea una base limpia de todo cambio posterior. Si se agregan objetos a template1.2. con -U el usuario con el se conectar´ a a postgres entre otros par´ ametros. pero PostgreSQL permite que se definan Bds espec´ ıficamente de plantilla. Se puede crear una Bd a partir de cualquier otra Bd. Existe una segunda plantilla.2. 2. lo cu´ al es especialmente valioso al restaurar un backup de pg dump ya que debe ser restaurado sobre una base de datos sin modificaci´ on alguna. La principal diferencia es que una Bd definida como template no puede ser eliminada y puede ser utilizada por cualquier usuario con capacidad de crear bases de datos como plantilla para una nueva BD. O desde la terminal: createdb -T template0 dbname Adem´ as de las plantillas predeterminadas. ya que al crear una base de datos tomando como plantilla template0. La principal base de datos plantilla es template1 a partir de la cual se crean todas las bases de datos en caso no se mencione otra plantilla.

No se puede ejecutar el comando DROP DATABASE mientras se est´ a conectado a la base de datos a ser eliminada. 2. schema. Eliminar una Base de datos implica destruir todo su contenido y es una acci´ on que no puede ser deshecha.3.mitabla (. se ejecuta el siguiente comando como superusuario: UPDATE pg_database SET datistemplate=true WHERE datname=’mi_bd’. Para crear una tabla en el nuevo esquema se debe utilizar: CREATE TABLE mi_esquema. Solo el due˜ no de una base de datos puede eliminarla. para eliminar bases de datos. Para crear un esquema en una BD. Eliminar una Base de Datos Las bases de datos se destruyen con el comando DROP DATABASE. incluyendo comandos para modificar la tabla.2. DROP DATABASE nombre_db. Se pueden dividir los esquemas por funcionalidad. Para acceder a un objeto en un esquema se escribe el nombre del esquema seguido por el nombre ddel objeto separados por un punto. leer y escribir datos. Creando Esquemas Los esquemas son una forma l´ ogica de partir una base de datos en mini contenedores. se debe hacerconectado desde otra base de datos.table Esta forma de nombrar una tabla funciona para toda aplicaci´ on. Existe un comando de consola.. dropdb nombre db 2. proveen una forma sencilla de repartir privilegios. 15 . usuarios o cualquier otro atributo que se desee. nos conectamos a la Bd y ejecutamos el comando: CREATE SCHEMA mi_esquema. dropdb..Si se ha dise˜ nado una Bd y se quiere convertirla en una plantilla. Adem´ as de la partici´ on l´ ogica.).3.

Los esquemas sirven por ejemplo para incluir m´ odulos externos (contrib) dentro de un esquema de tal manera que los nombres de sus objetos no puedan entrar en conflicto con el nombre de los objetos de la BD.1: Asignaci´ on de privilegios en Pgadmin3 16 . Gr´ afico 2. Otra forma de asignar permisos es mediante Pgadmin3. Se puede pensar en esquemas como en directorio pero sin la posibilidad de ser anidados. el cu´ al tiene una completa interfaz para asignar permisos.La ruta por defecto (search path) definida en postgresql. Los esquemas son tambi´ en utilizados para abstraer los nombres de las tablas. debido a que el nombre solo debe ser u ´nico dentro del esquema y muchas aplicaciones explotan esta caracter´ ıstica creando tablas con el mismo nombre en diferentes esquemas de tal manera que se carga una diferente dependiendo del usuario en el sistema. public. Lo cual significa que si hay un esquema con el mismo nombre que el del usuario en el sistema. entonces todos los objetos van a revisar primero el esquema con el mismo nombre del usuario y luego el esquema p´ ublico.conf es “$user”.

La sintaxis es: CREATE SCHEMA nuevo_esquema AUTHORIZATION usuario_curso. Es com´ un buscar que un esquema sea propiedad de otro usuario. Por ejemplo. Permisos Si se quiere dar permisos a un esquema que reci´ en se ha creado. ALTER DEFAULT PRIVILEGES IN SCHEMA contrib GRANT EXECUTE ON FUNCTIONS TO public. UPDATE ON SEQUENCES TO public. ALTER DEFAULT PRIVILEGES IN SCHEMA contrib GRANT SELECT.. se pueden dar permisos uno por uno o darle permisos a todos mediante GRANT . TRIGGER ON ALL TABLES IN SCHEMA contrib TO public.1. para que todos los usuarios de una BD tengan acceso a EXECUTE y SELECT en todas las tablas y funciones de un esquema que se creen a partir del momento en que se ejecuten se utilizar´ an los siguientes comandos: GRANT USAGE ON SCHEMA contrib TO public.3. GRANT SELECT. ALTER DEFAULT PRIVILEGES IN SCHEMA contrib GRANT SELECT. REFERENCES.2. Si el esquema ya est´ a definido con sus tablas y funciones. ALTER DEFAULT PRIVILEGES IN SCHEMA contrib GRANT USAGE ON TYPES TO public.. Los esquemas cuyo nombre empieza con pg son utilizados el sistema y no se recomienda su creaci´ on por los usuarios debido a que futuras versiones de Postgresql pueden utilizar el nombre elegido. 17 . para asi restringir las actividades de los usuarios a namespaces restringidos. ALL . GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA contrib TO public. UPDATE ON ALL SEQUENCES IN SCHEMA contrib TO public. IN SCHEMA. TRIGGER ON TABLES TO public. GRANT SELECT. REFERENCES. GRANT USAGE ON SCHEMA contrib TO public. se van a utilizar los comandos ALTER DEFAULT PRIVILEGES y GRANT.

adem´ as de que no es bueno “hardcodear” los nombres de los esquemas en las aplicaciones.4. adem´ as de ser el primer esquema en la ruta de b´ usqueda es tambi´ en el esquema por defecto donde se crearan las nuevas tablas si no se especifica un esquema en particular. El primer objeto con el nombre indicado que encuentre es escogido como el buscado.Cuando no se define expl´ ıcitamente un esquema. Ruta de B´ usqueda de Esquemas Los nombres completos incluyendo el del esquema son tediosos de escribir. Al llamar a las aplicaciones solo por su nombre.productos ( . Para eliminar un esquema incluyendo todos sus objetos utilizar: DROP SCHEMA myschema CASCADE.. El primer esquema en la ruta de b´ usqueda (search path) es llamado el esquema actual (current schema). el objeto creado entra en el esquema “public”. Para colocar un nuevo esquema en la ruta de b´ usqueda: SET search_path TO miesquema.public. 2. ). por lo cual es igual escribir: CREATE TABLE productos ( . 2. Para ver la actual ruta de b´ usqueda se utiliza: SHOW search_path. Eliminar esquemas Para eliminar un esquema este debe estar vacio (todos los objetos en su interior deben haber sido eliminados) y se utiliza: DROP SCHEMA myschema..2..3.. 18 . ). Y CREATE TABLE public. el sistema determina que tabla es buscando en todos los esquemas presentes.

Se puede crear un esquema para cada usuario con su propio nombre. es llamado un grupo.1. es un usuario. Si el rol puede ingresar a la BD. Roles En PostgreSQL solo existe un tipo de cuenta y es la de rol. en la pr´ actica puede ser u ´till mantener la correspondencia entre ambos pero no es necesario. Para crear un rol se utiliza CREATE ROLE : CREATE ROLE name. Los usuarios pueden referirse a los objetos agregados por su nombre completo o agregar el nuevo esquema en la ruta de b´ usqueda. Los roles pueden ser due˜ nos de objetos en las bases de datos (tablas por ejemplo) y pueden asignar privilegios a otros roles en esos objetos para controlar quien accede. Los roles de PostgreSQL no son iguales a los usuarios del sistema operativo. es posible hacer a un rol miembro de otros roles de tal manera que utilice sus privilegios. Utilizaci´ on de los esquemas Los esquemas se pueden utilizar para organizar la data de muchas formas diferentes.Lo cual har´ a que el nuevo esquema sea el primero en la ruta de b´ usqueda. Y para eliminarlo se usa DROP ROLE: DROP ROLE name. Algunos patrones de uso son recomendados: Si no se crean esquemas todos los usuarios acceden al esquema public. Para saber que roles han sido creados utilizar: 19 . 2. si queremos dejar de considerar public en la ruta de b´ usqueda se utiliza: SET search_path TO miesquema. Esta configuraci´ on es recomendada cuando hay solo un usuario o pocos usuarios cooperantes en la base de datos.5.4. Para instalar aplicaciones compartidas es recomendable colocarlas en sus propios esquemas y dar permisos a todos los usuarios para acceder a ese esquema. 2. Si se usa esta configuraci´ on se pueden revocar los permisos de los usuarios sobre el esquema public de tal manera que solo puedan utilizan sus propios esquemas. Adem´ as. Los roles puede ser parte de otros roles y cuando un rol tiene miembros.

Superuser: Un superusuario de una base de datos pasa por encima de toda restricci´ on excepto al ingresar al sistema. role creation: Para que un rol pueda crear otros roles se utiliza CREATE ROLE name CREATEROLE. se debe entrar con este usuario mediante psql o pgadmin y crear otros usuarios. Solo un superusuario puede crear otro superusuario. se crea por defecto una cuenta llamada postgres con una base de datos llamada postgres. Con otro comando SQL se crea un super usuario pero con un tiempo de vida limitado. La diferencia entre un rol y un usuario es que el usuario es creado con el atributo LOGIN que le permite ingresar a una base de dato.5. Para lograrlo se utiliza CREATE ROLE name CREATEDB. O el comando \du. Se puede incluir una fecha en la cual se espera que la cuenta desaparezca.2.5.1. Antes de hacer nada. Login: solo los roles que tienen el atributo LOGIN pueden ser utilizados como el nombre inicial a utilizar en una conexi´ on a una base de datos. database creation: A un rol se le debe dar de forma expl´ ıcita el permiso para crear bases de datos. CREATE ROLE regina LOGIN PASSWORD ’123456’ SUPERUSER VALID UNTIL ’2020-10-20 23:00’. 2. 20 . $ sudo su postgres -c “psql -d postgres” Mediante este comando SQL se crea un usuario con capacidad de crear bases de datos. initiating replication: Para que un rol pueda iniciar una replicaci´ on se debe dar permisos de replicaci´ on de login CREATE ROLE name REPLICATION LOGIN. Es un privilegio peligroso y debe ser otorgado con mucho cuidado. Infinity es una opci´ on por defecto por lo que no necesita ser considerada. Atributos de los roles Un rol puede tener diversos atributos que definan sus privilegios. 2. CREATE ROLE leo LOGIN PASSWORD ’qwerty’ CREATEDB VALID UNTIL ’infinity’. Crear un usuario Al terminar de instalar el gestor de Bds. Solo se puede crear un superusuario siendo un superusuario.SELECT rolname FROM pg_roles. Para crear un nuevo superusuario utilizar: CREATE ROLE name SUPERUSER.

En este estado la sesi´ on tiene acceso a los privilegios del role de grupo en vez de los privilegios 21 . Grupos Con frecuencia se agrupan usuarios para facilitar la gesti´ on de sus privilegios. Se puede crear un rol de grupo con: CREATE ROLE jungle INHERIT. Para crear un password se utiliza CREATE ROLE name PASSWORD ’string’. De esta manera los privilegios pueden ser otorgados o revocados en grupo. Los roles de grupo son roles que no tienen permiso para ingresar en el sistema pero tienen otros roles como miembros. Y asignar otro usuario a ese grupo mediante: GRANT jungle TO leo. Para remover miembros de un grupo se utiliza REVOKE.6. Por ejemplo: ALTER ROLE davide WITH PASSWORD ’hu8jmn3’. ALTER ROLE miriam CREATEROLE CREATEDB. Son en general una forma de que un conjunto de usuarios comparta permisos en com´ un. Los miembros de un grupo pueden utilizar sus privilegios de dos formas: Los miembros de un grupo pueden utilizar SET ROLE para “convertirse” momentaneamente en el grupo. ALTER ROLE worker_bee SET maintenance_work_mem = 100000.password: Un password solo es importante si el m´ etodo de autenticarse exige su utilizaci´ on. REVOKE leo FROM jungle. al crear un rol para convertirlo en un grupo. 2. Tal como se muestra. Los m´ etodos de autenticaci´ on password y md5. este debe ser capaz de heredar sus permisos. Cambiar atributos Para cambiar los atributos de un rol se utiliza ALTER ROLE.

Los cinco tipos son: trust: Confia en el usuario que se conecta. CREATE ROLE wheel NOINHERIT.conf. El tipo de m´ etodo se define en pg hba. este archivo de configuraci´ on controla que usuarios pueden conectarse al servidor PostgreSQL. GRANT admin TO joe. Md5: Es el m´ as com´ un de los m´ etodos y requiere un password cifrado mediante md5. Para definir el tipo de autenticaci´ on se utiliza el archivo pg hba. Al conectarse como joe. En segundo lugar los roles miembros que tengan el atributo INHERIT tienen acceso a los privilegios de los roles de los que son miembros. Password: significa autenticarse mediante un password en texto plano. Es la m´ as com´ un en bases de datos instaladas en una computadora para un solo usuario. Ident: utiliza el SO para identificar si existe la cuenta del usuario intentando conectarse en el SO. Por ejemplo: CREATE ROLE joe LOGIN INHERIT. la sesi´ on tiene los permisos de admin pero no los de wheel. Control de Acceso PostgreSQL dispone de varios m´ etodos de autenticaci´ on para validar usuarios. GRANT wheel TO admin. CREATE ROLE admin NOINHERIT. Si se ejecuta: SET ROLE admin.originales con los que se registro y cualquier objeto creado ser´ a propiedad del rol de grupo. La sesi´ on solo tendr´ a los privilegios de admin debido a que no hereda. No utiliza password.conf. 2. 22 . incluyendo cualquier privilegio heredado por esos roles.7. Solo valida que su IP y usuario sean correctos sin importar la contrase˜ na.

Crear un esquema llamado “esquema prueba” propiedad de usuario prueba. 3. Configurar PostgreSQL para que pueda ser accedido desde toda IP. Crear una base de datos llamada “Base plantilla” y convertirla en una plantilla. Crear una tabla Producto en ambos esquemas con los campos nombre. Crear una base de datos llamada “base copia” tomando como base a Base plantilla. Insertar datos diferentes en ambas tablas. esquemas y roles utilizando a usuario creador. 12. 6. 4. Hacer a usuario prueba miembro de grupo prueba.Ejercicios: 1. precio y cantidad. 8. esquemas y roles. Agregar dos tablas a Base plantilla. Crear un usuario llamado “usuario creador” y darle permiso para crear bases de datos. Crear un usuario llamado “usuario prueba”. Crear bases de datos. 14. 23 . 5. 13. Crear un esquema llamado “esquema curso” propiedad de usuario curso. 7. Crear un grupo llamado “grupo prueba”. 9. 2. 11. Ordenar los esquemas de manera tal que al escribir “SELECT * FROM Productos” se vea en pantalla la tabla Productos de esquema prueba. 10.

toda la transacci´ on se cancela. sin importar el estado actual de la data subyacente. Dadas las siguientes operaciones: UPDATE accounts SET balance = balance . disco duro). Definici´ on de Transacci´ on Las transacciones son uno de los conceptos fundamentales de todos los sistemas de bases de datos. si una sola de las operaciones falla. Esto protege a la transacci´ on de ver data inconsistente que puede haber sido causada por otras transacciones concurrentes en los mismos registros. Si un conjunto de operaciones de una transacci´ on afectan a varios tablas en una base de datos.00 24 . ej.1. MVCC). La consistencia de la data es mantenida internamente utilizando un modelo de multiversi´ on (Multiversion Concurrency Control. ninguno de los pasos previos afecta a la base de datos. adem´ as. [2] 3. todas las actualizaciones hechas la BD son guardadas en almacenamiento permanente (p. Proveyendo aislamiento de la transacci´ on para cada sesi´ on en la BD. antes de darse por terminada la transacci´ on. Una transacci´ on es at´ omica. que evita que la transacci´ on se complete. Esto significa que al consultar una Base de Datos cada transacci´ on ve una “instant´ anea” de la data tal como era alg´ un tiempo antes. si en un banco se realiza una transferencia entre dos cuentas y una operaci´ on resta dinero de una cuenta pero otra operaci´ on no puede a sumarlo al destinatario.Cap´ ıtulo 3 Transacciones y concurrencia PostgreSQL provee las herramientas para gestionar el acceso concurrente a la data. todas las dem´ as operaciones quedan sin efecto y la base de datos no es modificada por la transacci´ on. desde el punto de vista de otras transacciones o se lleva a cabo completamente o no en absoluto. La principal ventaja de utilizar el modelo MVCC de control de la concurrencia en vez del bloqueo de registros es que en MVCC los bloqueos por leer data no interfieren con los bloqueos por escribir data en un registro as´ ı las operaciones no se bloquean entre si.100. Los pasos intermedios antes de culminar la transacci´ on no son visibles para las transacciones concurrentes y si alguna falla ocurre. Por ejemplo. El punto esencial es que una transacci´ on engloba un m´ ultiples pasos en una sola operaci´ on donde se ejecuta todo o nada.

Es por esto que las transacciones deben ser “todo o nada” no solo en sus efectos permanentes en la base de datos sino en la visibilidad de sus resultados a medida que avanza. Por defecto.00 WHERE name = ’Bob’.El banco por supuesto desea estar seguro de que las transacciones realizadas tengan ´ exito todas o ninguna se lleve a cabo. cada una no debe de ser capaz de ver los cambios incompletos llevados a cabo por otros. Por ejemplo. UPDATE accounts SET balance = balance + 100. donde todos los cambios a la data se vuelven visibles simultaneamente. Es por esto que los resultados de una transacci´ on son invisibles para otras transacciones hasta que la transacci´ on termina. -. UPDATE branches SET balance = balance + 100. si una transacci´ on est´ a ocupada cuadrando los balances de caja no deber´ ıa ver solo la transacci´ on iniciada por Alice o Bob. Otra propiedad importante de las transacciones es el aislamiento: cuando m´ ultiples transacciones est´ an ejecutandose al mismo tiempo.etc etc COMMIT.100. por ejemplo: BEGIN.00 WHERE name = ’Alice’. caso contrario la data guardada no sera coherente. En PostgreSQL una transacci´ on se lleva a cabo utilizando los comandos BEGIN y COMMIT al inicio y fin de la transacci´ on. colocando BEGIN al inicio de la transacci´ on y COMMIT al final si es exitosa. PostgreSQL trata a cada comando SQL como una transacci´ on.00 WHERE name = (SELECT branch_name FROM accounts WHERE name = ’Alice’). 25 . Una transacci´ on adem´ as debe de ser registrada y guardada de forma permanente antes de reportarse como terminada.00 WHERE name = (SELECT branch_name FROM accounts WHERE name = ’Bob’). UPDATE accounts SET balance = balance .100. sino el resultado final de toda la transacci´ on. podemos eliminar todos los cambios mediante el comando ROLLBACK. Si en alg´ un punto de la transacci´ on decidimos no hacer commit. UPDATE branches SET balance = balance . lo crucial es que hay varias actualizaciones envueltas en una sola operaci´ on. Para garantizar que situaciones as´ ı no se produzcan se agrupan las operaciones en transacciones. Los detalles de los comandos no son importantes.WHERE name = ’Alice’.

00 WHERE name = ’Bob’. Phantom read: Una transacci´ on vuelve a ejecutar una consulta que devuelve un conjunto de registros que satisfacen determinada condici´ on de b´ usqueda y encuentra que este conjunto de registros a cambiado debido a otra transacci´ on concurrente. Regresando al ejemplo del banco. Todos los cambios a la base de datos entre la definici´ on del Savepoint y el rollbak son descartadas. la transacci´ on podr´ ıa ser la siguiente: BEGIN. Nonrepeatable read: Una transacci´ on vuelve a leer data que ha leido previamente y encuentra que ha sido modificada por otra transacci´ on que env´ ıo data despu´ es de enviada la actual transacci´ on. se puede hacer ROLLBACK TO de regreso al savepoint. SAVEPOINT my_savepoint. Despu´ es de definir un Savepoint en una transacci´ on .En realidad mejor utilizamos la cuenta de Wally ROLLBACK TO my_savepoint. Los cuatro niveles y sus respectivos comportamientos seg´ un PostgreSQL: 26 . UPDATE accounts SET balance = balance . Savepoints Es posible controlar las operaciones en una trasacci´ on de una forma m´ as fina mediante el uso de savepoints.00 WHERE name = ’Alice’. 3. Se puede regresar a un savepoint varias veces en el transcurso de una transacci´ on. Los savepoints permiten descartar selectivamente partes de una transacci´ on y enviar (commit) el resto a la BD. COMMIT. Los comportamientos son: Dirty read: Una transacci´ on lee data escrita por una transacci´ on a´ un no enviada (commited).00 WHERE name = ’Wally’.1. ROLLBACK es la u ´nica manera de recuperar el control de una transacci´ on que ha sido bloqueada por el sistema debido a un error en una de sus transacciones. pero los cambios previos al Savepoint son guardados. UPDATE accounts SET balance = balance + 100.1.2.100. -. Niveles de Aislamiento de las Transacciones Existen cuatro niveles de aislamiento de las transacciones en el est´ andar SQL. cada uno de los cuales permite que se lleven o no a cabo tres comportamientos. UPDATE accounts SET balance = balance + 100.3.

Luego en una sesi´ on B ejecutar: 27 . Detalle de los niveles de aislamiento Los niveles de aislamiento (isolation levels) son un aspecto central en el manejo de las transacciones por lo cual lo abordaremos con detalle. un SELECT solo ve data enviada antes de que la consulta empiece. SET TRANSACTION ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }. Read uncommitted se mantiene para fines de compatibilidad. BEGIN. Para establecer el nivel de aislamiento de una transacci´ on se utiliza SET TRANSACTION. por lo que diferentes SELECT dentro de una misma transacci´ on pueden ver diferente data en la BD.1: Niveles de aislamiento Como se puede observar. SELECT si ve los cambios efectuados dentro de la transacci´ on as´ ı no hayan sido a´ un enviados. ya no se puede cambiar el nivel de aislamiento de la transacci´ on. Read commited Es el nivel de aislamiento por defecto en PostgreSQL. Adem´ as. Por ejemplo. Sin embargo. Cuando una transacci´ on utiliza este nivel.1. SELECT * FROM tabla_ejemplo. en una sesi´ on A ejecutar los siguientes comandos sobre una tabla existente.Isolation Level Read uncommitted Read committed Repeatable read Serializable Dirty Read Not possible Not possible Not possible Not possible Nonrepeatable Read Possible Possible Not possible Not possible Phantom Read Possible Possible Not possible Not possible Tabla 3. 3. Read uncommitted y Read commited son iguales seg´ un la implementaci´ on de PostgreSQL y el valor adicional de Serializable sobre Repeteable Read es el monitoreo para evitar que transacciones concurrentes no puedan ser serializadas.2. cada SELECT ve datos diferentes si otra transacci´ on ha cambiado los datos antes de que empiece a ejecutarse. Una vez realizada la primera consulta. SET TRANSACTION ISOLATION LEVEL READ COMMITTED. nunca ve data no enviada (uncommitted) o cambios enviados por transacciones concurrentes durante la ejecuci´ on de la consulta.

el comando va a esperar a que los cambios se env´ ıen o se descarten. reevaluando la condici´ on de b´ usqueda (WHERE) para comprobar si se sigue aplicando..UPDATE tabla_ejemplo SET . Los comandos de escritura (UPDATE.. WHERE . Se puede observar que los dos select en la misma transacci´ on devolvieron resultados diferentes. Por ejemplo. END.. WHERE . como en la siguiente transacci´ on. En otra sesi´ on B ejecutar: BEGIN: SET TRANSACTION ISOLATION LEVEL READ COMMITTED.. SELECT FOR UPDATE y SELECT FOR SHARE) se comportan igual que SELECT al buscar registros: solo van a encontrar los registros que ya estaban enviados (committed) al empezar el comando. UPDATE tabla_ejemplo SET . DELETE. BEGIN... por ejemplo un comando DELETE que opere en data que ha sido agregada y removida de su criterio de b´ usqueda por otro comando.. -. UPDATE tabla_ejemplo SET .. UPDATE website SET hits = hits + 1....Execute in other sesion: DELETE FROM website WHERE hits = 10. Debido a lo explicado. 28 . Si los cambios de la transacci´ on anterior se env´ ıan.... el modo Read committed puede llevar a ver una instant´ anea inconsistente de la BD: puede ver los efectos de actualizaciones concurrentes en las registros que est´ a procurando actualizar pero no ve los efectos de estos comando en otros registros de la BD. la segunda transacci´ on se quedar´ a esperando el resultado. la segunda transacci´ on va a ignorar el registro si ha sido eliminado por la primera o va a tomar en cuenta los cambios si ha sido modificado. Mientras la primera transacci´ on no termine.. Si el registro ha sido modificado despu´ es de que empez´ o el comando. WHERE . En la sesi´ on A volver a ejecutar un SELECT y terminar la transacci´ on: SELECT * FROM tabla_ejemplo.... abrir una sesi´ on A y ejecutar: BEGIN: SET TRANSACTION ISOLATION LEVEL READ COMMITTED. Usos complejos de la Bd pueden producir resultados indeseados en el modo Read Committed.

Los comandos que actualizan data (UPDATE. A´ un as´ ı. las aplicaciones deben estar listas para cancelar transacciones debido a 1 2 [2] pp. DELETE. Es debido a esta caracter´ ıstica que Read Committed no es adecuado para todos los casos. pero definiendo Repeatable Read como nivel de aislamiento utilizando: SET TRANSACTION ISOLATION LEVEL REPEATABLE READ.COMMIT. no se va a poder llevar a cabo la operaci´ on y toda la transacci´ on va a ser cancelada con el siguiente mensaje: ERROR: could not serialize access due to concurrent update Cuando una aplicaci´ on recibe este mensaje de error debe cancelar la actual transacci´ on y volverla a empezar de cero.1 Repeatable Read Este nivel solo ve ve data enviada antes de que la transacci´ on haya empezado. de forma serial en vez de concurrente. Este nivel de aislamiento previene todos los comportamientos mencionados en la tabla anterior. nunca ve data no enviada o enviada despu´ es de que la transacci´ on haya empezado.2 En este nivel. SELECT FOR UPDATE y SELECT FOR SHARE) tienen el mismo comportamiento del SELECT al buscar registros pero en caso de que un registro este siendo modificado por una transacci´ on concurrente van a esperar que acabe y si el registro ha sido modificado. data anterior a que la transacci´ on empezara a ejecutarse. Serializable Este nivel provee el aislamiento m´ as estricto para las transacciones. Por ejemplo. como si hubieran sido ejecutadas una despu´ es de la otra. Si embargo la transacci´ on si ve los cambios enviados dentro de si aunque a´ un no hayan sido enviados. Esta segunda vez la transacci´ on vera las actualizaciones llevadas a cabo en los registros por las otras transacciones. 342 [2] pp. los SELECT dentro de una transacci´ on ven todos la misma data en la BD. ya que los que tienen 9 antes de la actualizaci´ on siguen siendo vistos como 9 por el DELETE concurrente y los que tienen 10 est´ an siendo modificados por la primera transacci´ on por lo que el DELETE debe esperar a que termine la actualizaci´ on y en ese momento su valor ser´ a de 11. 343 29 . Los valores que tengan 10 antes o despu´ es de la actualizaci´ on no van a ser afectados. Este nivel de aislamiento provee una rigurosa garant´ ıa de que cada transacci´ on ver´ a una imagen estable de la BD dentro de si. A´ un as´ ı. Este nivel emula ejecuci´ on serial de las transacciones. llevar a cabo la misma prueba con el SELECT que con Read commited. este nivel puede tener problemas debido a transacciones concurrentes que provoquen continuas cancelaciones de una transacci´ on.

(SELECT SUM(value) FROM mytab WHERE class = 2)). Por ejemplo. dada la tabla mytab: Class Value 1 1 2 2 Tenemos dos transacciones. Y obtiene el resultado 300 el cual inserta en un registro cuyo campo class = 1. la transacci´ on A es: 10 20 100 200 INSERT INTO t VALUES (2. el cual consiste en analizar las transacciones para verificar si el orden de ejecuci´ on es consistente con el resultado. se puede tener confianza de que va a hacerlo bien en un conjunto de transacciones a´ un sin informaci´ on sobre lo que el resto de transacciones va a hacer. el modo Serializado va a permitir a una transacci´ on enviar su data a la BD y la otra va a ser cancelada con el mensaje: ERROR: could not serialize access due to read/write dependencies among transactions Esto se debe a que si A se ejecuta antes de B. 30 . significa que si se puede demostrar que cada transacci´ on por separado va a tener el resultado esperado al ejecutarse. la transacci´ on B es: INSERT INTO t VALUES (1.fallas en la serializaci´ on. Y luego inserta el resultado (30) en el campo value de un nuevo registro cuyo campo class = 2. como no hay un orden serial de ejecuci´ on consistente con el resultado. Para garantizar la serializaci´ on PostgreSQL utiliza “predicate locking” o bloqueo por predicados. Concurrentemente. B hubiera obtenido un resultado de 330 no 300 y al rev´ es hubiera resultado en A con el valor de 330 como resultado. (SELECT SUM(value) FROM mytab WHERE class = 1)). El bloqueo por predicados en PostgreSQL. La garant´ ıa de que un conjunto de transacciones concurrentes serializables va a tener el mismo efecto que si se ejecutaran una tras otra. Este nivel trabaja igual que Repeatable Read a excepci´ on de que monitorea las condiciones que pueden hacer que un conjunto serializable de transacciones concurrentes se comporte de manera inconsistente con todas las posibles ejecuciones seriales de estas transacciones. Luego ambas transacciones hacen commit. est´ a basado en la data accedida por la transacci´ on.

el m´ odulo de PostgreSQL que elimina peri´ odicamente los registros que ya no van a ser utilizados.3. Bloqueo a nivel de tablas y registro est´ a disponible en PostgreSQL para aplicaciones que generalmente no necesitan aislar completamente las transacciones y prefieren manejar gestionar explicitamente los puntos de conflicto. Un bloqueo es ejecutado por un comando como SELECT o UPDATE para tener acceso a la data con la que est´ an trabajando. que empieza vac´ ıo para indicar que el registro no ha sido borrado. el ID de la actual transacci´ on se convierte en su xmax . Xmin y xmax son en esencia el tiempo de vida visible del registro en t´ erminos de Ids. PostgreSQL mantiene la garant´ ıa de que no va a necesitar bloquear ambos a´ un al proveer los m´ as estrictos niveles de aislamiento de la transacci´ on. Cuando se borra un registro. solo incluye un registro con xmax si este es anterior al XID de la consulta. Descripci´ on del Control de Concurrencia Al crear o modificar un registro. para indicar que no va a ser m´ as visible despu´ es de ese punto en el tiempo (o mejor dicho en el hist´ orico de transacciones). el m´ ınimo XID capaz de ver este trozo de informaci´ on una vez ha sido enviado. Cada registro tiene un XID de eliminaci´ on. En general todas las consultas llevan a cabo alguna forma de bloqueo sobre la data a la que acceden. 3. El registro original va a ser eliminado despu´ es de un tiempo por VACUUM.4. Diferencias entre MVCC y Bloqueo PostgreSQL provee varios modos de bloqueo para para controlar el acceso concurrente a la data en las tablas. 31 . en cambio MVCC es un modelo de trabajo del gestor de base de datos para permitir que varias transacciones al mismo tiempo (concurrencia) puedan acceder a la misma data en la BD. Un mecanismo similar gestiona la eliminaci´ on. Cuando una consulta es ejecutada utiliza el ID de la actual transacci´ on como un l´ ımite para lo que puede considerarse visible. Al ejecutarse una consulta. tambi´ en llamado el xmax. La principal ventaja de utilizar el modelo MVCC sobre bloqueo es que los bloqeuos de MVCC para escribir data no entran en conflicto con los bloqueos para leer data. Los registros cuyo xmin es menor que el ID de la transacci´ on y han sido enviados son considerados para ser mostrados en la consulta. [5] Para ver los ids en funcionamiento se puede utilizar la funci´ on txid current snapshot().3. el nuevo registro as´ ı creado guarda el ID de la transacci´ on en un campo llamado XID tambi´ en llamado xmin. El registro solo es visible desde una consulta cuyo XID este entre ambos.

dependiendo de la configuraci´ on del servidor se toma una decisi´ on. $ psql -d Bd prueba 2. i INTEGER). Para probar cr´ eese una tabla y un registro en la BD: 1.1. no se va a ver el cambio hecho en la segunda hasta que sea enviado. 3. CREATE TABLE t (s SERIAL. Si otra sesi´ on intenta modificar un registro que ya est´ a siendo modificado espera a que termine la primera transacci´ on. UPDATE t SET i=100 WHERE s=1. Ejemplo MVCC UPDATES Si dos sesiones al mismo tiempo procuran alterar un registro una de las dos esperar´ a hasta que la otra termine. INSERT into t(i) values (0) 4. 32 . 3. caso contrario la segunda transacci´ on no afecta al registro.3. Para ver los valores xmin y xmax SELECT xmin. si ese es el caso se procede con el cambio. Para ver el id de la ctual transacci´ on select txid current().5. Una vez que la primera sesi´ on termina. Para ver el id de la actual transacci´ on. la segunda transacci´ on no puede modificar el registro y aparece un error: • ERROR: could not serialize access due to concurrent updates • Y la sesi´ on no tiene otra opci´ on que eliminar la transacci´ on en curso. El otro modo de configuraci´ on es la Serializaci´ on. en el cual la existencia de otra sesi´ on que modifica el mismo registro solo provoca que se verifique si las condiciones para cambiar el registro a´ un existen en el registro cambiado por la primera transacci´ on. 3. • Este modo se utiliza cuando se requiere que la sesi´ on opere con una vista id´ entica de la BD. Begin. SELECT txid current(). Desde la perspectiva de la segunda sesi´ on el registro se ha actualizado. si la transacci´ on original se termina.5. Actualizar el registro 4. Para iniciar la transacci´ on. 1. Luego desde otra sesi´ on in´ ıciese una transacci´ on mediante Begin y actual´ ıcese el registro pero no se env´ ıe (commit) a´ un. Una configuraci´ on es el modo por defecto Read Committed.xmax from t. 5. pero si hacemos un select en la primera sesi´ on. 2.

este no cambia el registro en si.2. Al eliminar un registro. DELETE Al eliminar un registro hay algunas diferencias con modificarlo. sino su informaci´ on de visibilidad para que ya no sea visible por otras sesiones.5. este no se puede ir hasta que toda sesi´ on que lo pueda necesitar haya terminado. Al eliminar un registro.3. 33 .

3. La primera debe leer una tabla y la segunda debe insertar registro en esa tabla. 5. Crear una tabla llamada ”tabla transacciones”. 7.Ejercicios: 1. una debe eliminar un registro y la otra actualizarlo. ambas deben actualizar el mismo registro. Crear una transacci´ on en cada sesi´ on. Observar el resultado. Crear dos transacciones de tipo SERIALIZABLE. Crear dos transacciones de tipo REPEATABLE READ. una de tipo REPEATABLE READ y la otra con el nivel por defecto. en una agregar un registro y en la otra eliminar un registro (diferentes). Abrir dos sesiones con el mismo usuario. 2. Crear otras dos transacciones. Crear tres registros en la tabla. 4. 8. Crear dos transacciones. en ambas eliminar diferentes registros. 6. 34 .

Cap´ ıtulo 4 Ajustes de rendimiento
PostgreSQL es una gran plataforma sobre la cual desarrollar aplicaciones y soluciones empresariales, pero optimizar el rendimiento no ha sido una tarea f´ acil. Se necesitan adecuadas reglas emp´ ıricas para comenzar as´ ı como supervisi´ on y mantenimiento para mantener el sistema ejecut´ andose sin problemas y con el rendimiento esperado. En general para ajustar el rendimiento de una Base de Datos en PostgreSQL se siguen los siguientes pasos: Seleccionar el hardware donde ejecutar la BD, idealmente se debe probar el hardware para estar seguro de que su rendimiento es el esperado. Configurar toda la implementaci´ on del hardware y software de disco: nivel RAID, sistema de archivos. Optimizar la configuraci´ on del Servidor. Supervisar el rendimiento del servidor y cu´ an bien se est´ an ejecutando las consultas. Mejorar las consultas para que se ejecuten de forma m´ as eficiente y agregar ´ ındices para acelerarlas. Introducir pool de conexiones y cache. Replicar la data en m´ ultiples servidores y distribuir las lecturas entre todos. Partir grandes tablas en secciones, eventualmente, las m´ as grandes pueden ser divididas entre varios servidores.

4.1.

Configuraci´ on de Hardware

Una raz´ on importante para utilizar un gestor de c´ odigo abierto como PostgreSQL es que cada d´ olar ahorrado en el software se puede invertir en hardware. Los tres principales componentes a considerar en el presupuesto son CPU, memoria y discos.

35

4.1.1.

CPU

Actualmente los CPUs tienen dos o m´ as n´ ucleos, lo cu´ al lleva a los desarrolladores a preguntar dos cuestiones esenciales: 1. ¿Qu´ e familia de procesadores es mejor? 2. ¿Qu´ e es mejor?, ¿m´ as n´ ucleos o n´ ucleos m´ as r´ apidos? En general se considera que Intel produce n´ ucleos m´ as r´ apidos y AMD provee m´ as n´ ucleos por d´ olar y sobre todo sus servidores tienen capacidad para tener mayor cantidad de n´ ucleos que los de la competencia. Para saber si se requieren m´ as n´ ucleos o m´ as r´ apidos es necesario supervisar los procesos existentes en el sistema. Si hay pocos procesos utilizando cada uno un CPU, entonces el servidor se beneficiaria en tener n´ ucleos m´ as r´ apidos, esto tiende a pasar cuando se tienen procesos batch donde se procesan grandes cantidades de data. Pero si est´ an activos todos los CPUs con muchos procesos concurrentes, entonces el sistema mejorar´ ıa su rendimiento utilizando m´ as n´ ucleos, lo c´ ual es com´ un en aplicaciones con gran cantidad de usuarios accediendo a la BD. Otra situaci´ on donde es u ´til tener n´ ucleos m´ as veloces es al exportar o importar grandes cantidades de datos de la BD, proceso en el c´ ual el cuello de botella puede ser la CPU.

4.1.2.

Memoria

Cuanta memoria es necesaria para para una aplicaci´ on depende del tama˜ no de la data de trabajo con el cual se ejecutan el com´ un de operaciones. Generalmente agregar RAM mejora el rendimiento pero hay casos en los que no: Si el conjunto de data es suficiente para entrar en la RAM existente, m´ as RAM no va a producir grandes beneficios, mejor rendimiento se va a obtener agregando procesadores m´ as veloces. Cuando la data es tan grande que no puede entrar en cantidad de memoria alguna, por lo que es m´ as u ´til aumentar la velocidad de los discos. Aumentar la memoria ayuda as´ ı no toda la data entre, ya que el cach´ e aumenta y por lo tanto los bloques m´ as utilizados van a permanecer en memoria, aumentado as´ ı el rendimiento.

4.1.3.

Discos

Los discos SAS son m´ as confiables y r´ apidos que los SATA. Los discos enterprise SATA son mejores para RAID ya que informan r´ apidamente de los errores y el controlador RAID reconstruye la data errada. Los discos SAS en cambio procuran arreglar por si mismos el problema, ralentizando el arreglo de discos. Es buena pr´ actica poner en producci´ on solo discos que tengan tiempo en el mercado de tal manera que sus fallas ya hayan sido reportadas y corregidas. Los discos de estado s´ olido son m´ as veloces que los discos magn´ eticos tradicionales, sobre todo al buscar informaci´ on, pero a´ un no tienen la capacidad de almacenamiento de los discos magn´ eticos y son considerablemente m´ as caros. 36

4.2.

Configuraci´ on del S.O.

La configuraci´ on del Sistema Operativo para soportar una base de datos PostgreSQL incluye el sistema de archivos y los par´ ametros de disco.

4.2.1.

Hdparm

En el caso de los *nix, para hacer m´ as seguro el sistema para una Base de Datos, se debe inhabilitar el cache de escritura mediante el comando: sudo hdparm -W 0 /dev/sda

4.2.2.

Sistemas de archivos

La escritura en sistemas de archivos tienen dos componentes principales: Los bloques de datos que se escriben en el disco. La metadata del sistema de archivos. Al agregar un bloque de data en un archivo existente, se llevan a cabo las siguientes operaciones: Agregar la informaci´ on del nuevo bloque a la metadata de espacio de disco utilizado. Escribir el bloque de data. Escribir la metadata del archivo referenciando el uso del nuevo bloque. En caso de que se caiga el sistema a mitad de la operaci´ on, no se va a sobrescribir el nuevo bloque debido a que desde un inicio fue tomado en cuenta como un bloque utilizado.

4.2.3.

Journaling

La forma actual de trabajar de los sistemas de archivos es mediante journaling, t´ ecnica por la cual se escribe el inicio y fin de cada escritura en el journal, se escribe la metadata del sistema de archivos y del archivo, el bloque de datos y su utilizaci´ on. El journaling es algo pesado debido a que por cada operaci´ on en disco se debe escribir varias veces en el journal. Este se lleva a a cabo de la siguiente manera: Escribe la metadata del inicio de la transacci´ on en el journal. Escribe la metadata del cambio de espacio utilizado en el journal. Escribe el cambio en el bloque de datos en el journal. Escribe el cambio en la metadata del archivo en el journal. Agregar el bloque de data a la metadata de la lista de espacio utilizado. Escribe el bloque de data. Escribe metadata del archivo referenciando el uso del bloque. 37

2. ya que toda transacci´ on es escrita cuatro veces. El tama˜ no m´ aximo para las particiones es de 16TB y para los archivos es de 2TB en ext3. 4. Configuraci´ on del sistema de archivos en Linux Sin importar el sistema de archivos que se utilice. solo los cambios en la metadata. pero el orden en que son guardados relativo a los bloques de data no es garantizado. Despu´ es de una ca´ ıda del sistema.4. 38 . los archivos pueden quedar con basura al final por escrituras incompletas y se puede tener una mezcla de data vieja y nueva sobre los archivos. Con estas operaciones se obtiene la habilidad de recuperar el sistema de cualquier caida.2. Para superar este problema se debe colocar: full page writes = on en postgresql. que se definen como opciones al montarse el sistema de archivos: data=writeback : Los cambios en la data no son guardados en el journal. por lo que se parece al modo writeback de ext3 y es considerado inseguro. Este enfoque hace que sea pesado utilizar el journaling completo con una base de datos. data=ordered : La metadata es guardada en el journal pero no los cambios en la data.Escribe la metadata del fin de la transacci´ on en el journal. pero en todos los casos la metadata es escrita solo despu´ es de que los bloques de data hayan sido escritos. ya que PostgreSQL se encarga de la integridad de su data. XFS XFS es m´ as veloz que los ext debido a que fue dise˜ nado para ser eficiente en el journaling. con la base de datos se utiliza solo journaling de la metadata. Despu´ es de una caida de sistema. 4. en PostgreSQL no es necesario utilizar journaling completo. Si no se llega a terminar una transacci´ on de escritura el sistema de archivos puede ignorar o deshacer cualquier trabajo parcial hecho hasta el momento. existen configuraciones que pueden mejorar su rendimiento. por lo que la opci´ on ordered va a permitir mayores velocidades. Para evitar la sobrecarga de trabajo.conf. l´ ımite que busca ser superado por ext4. muy superior a los sistemas de archivos ext. Ext Sistemas de archivos de Linux Las versiones modernas de Ext (3 y 4) tienen tres niveles de journaling. XFS tiene la ventaja de que es m´ as eficiente al ser utilizado con RAID y adem´ as puede soportar archivos de m´ as de un mill´ on de TB. no van a haber archivos de tama˜ nos incorrectos. Debido a que realiza su propio chequeo de la integridad de los datos. pero solo registra los cambios de la metadata en el journal. data=journal : Journaling completo Los cambios en la data y la metadata son escritos en el journal antes de que el sistema de archivos sea tocado.5.

overcommit memory=2 39 . ahorrando as´ ı mucho tiempo. /dev/sda1 ext3 noatime. esta funcionalidad hace que el Sistema Operativo solicite los bloques del disco antes de que la aplicaci´ on los solicite. al igual que PostgreSQL. se accede a /proc/sys/vm/swappiness mediante el comando: sudo less /proc/sys/vm/swappiness Y la forma m´ as f´ acil de ajustarlo es agregar la siguiente l´ ınea en /etc/sysctl.Read ahead El primer par´ ametro a configurar en Linux es el read-ahead de los dispositivos de almacenamiento. Otro par´ ametro relacionado es el que controla la tendencia de Linux a permitir que los procesos separen m´ as memoria de la que necesitan. Cuando se hacen lecturas secuenciales que se mueven hacia adelante. compitiendo ambos por el recurso. la cu´ al se puede desactivar mediante el par´ ametro en /etc/sysctl. lo cual redunda en un incremento de la perfomance en la mayor´ ıa de casos. Cuando el sistema tiene poca RAM. Este comportamiento est controlado por el par´ ametro swappiness del kernel. se actualiza un atributo del archivo llamado el tiempo del u ´ltimo acceso (atime).errors=remount-ro 0 1 Cache de lectura e intercambio de p´ aginas Linux procura utilizar todo espacio extra de RAM para poner en cache el sistema de archivos.conf: vm. Para ver el valor actual del par´ ametro.O en vez de aumentar el swapping. lo cu´ al no es deseable.conf: vm. Esta sobrecarga se vuelve grande cuando se hacen muchas lecturas de un archivo.swappiness=0 El valor de 0 disminuye el tam˜ no del cache del S. Se puede eliminar este comportamiento agregando el par´ ametro noatime a las opciones de montaje en /etc/fstab. Para ver el estado actual de read-ahead se ejecuta el comando: $ blockdev –getra /dev/sda Para mejorar este par´ ametro se le aumenta a un valor entre 4096 y16384 mediante el siguiente comando: $ blockdev –setra 4096 /dev/sda Tiempo de acceso a los archivos (File access times) Cada vez que se accede a un archivo en Linux. debe optar por reducir el tama˜ no del cache o incrementar el intercambio de p´ aginas con el disco (swapping).

Unidades de memoria en postgresql. el par´ ametro work mem limita la cantidad de memoria que puede ser utilizada para ordenamiento y puede ser incrementado por el cliente luego de conectarse. Entre los sistemas de archivos de FreeBSD. 40 .conf Para indicar la memoria que se quiere asignar a un par´ ametro hay que especificar la unidad de memoria. lo cu´ al es u ´til cuando se leen grandes cantidades de informaci´ on pero ineficiente cuando las lecturas son m´ as peque˜ nas y al azar. que para este par´ ametro son bloques de 8K. Para llevarlo a cabo se utiliza el siguiente comando: $ zfs set recordsize=8K zp1data Esta configuraci´ on se debe hacer antes de crear ninguna Bd en el dispositivo de almacenamiento. ZFS En ZFS. Adicionalmente todo cliente que se conecta utiliza una cantidad de memoria.3. utilizando memoria no ocupada por otros procesos. se recomienda reducir el tama˜ no del registro de ZFS para igualarlo al de PostgreSQL de 8KB. Monitorear y optimizar como se usa esta memoria es el objetivo de la presente secci´ on. Por ejemplo. El mayor componente de la memoria compartida es la cache. En caso de que las lecturas sean de peque˜ nas cantidades de informaci´ on al azar. BSD Los sistemas BSD. ZFS es el m´ as utilizado. 4. la que se define por un par´ ametro llamado shared buffers. Algunos par´ ametros de la base de datos pueden ser definidos por los clientes a medida que se conectan.2. Memoria para el cache de la Base de Datos Cuando se inicia un servidor PostgreSQL. por defecto se utilizan registros de 128KB de tama˜ no. si se desea especificar el tama˜ no del par´ ametro wal buffers que controla cuanta memoria utiliza usar para el buffer del WAL.4. en especial FreeBSD han sido conocidos por su alta calidad. se escribe lo siguiente en postgresql. sobre todo en la implementaci´ on de servidores.3. por ejemplo.6.1.conf: wal buffers = 64 KB La base de datos internamente convierte el valor en sus propias unidades internas. ZFS tiene funcionalidades que lo hacen muy apto para las bases de datos como implementar sumas de comprobaci´ on en toda lectura y escritura de bloques de datos y mayor velocidad para copiar grandes cantidades de informaci´ on. este reserva una cantidad fija de bloques de memoria. aumentandola a medida que el cliente utiliza recursos y realiza operaciones como ordenamientos y guarda data de transacciones en espera del commit. 4.

tro shared buffers es un n´ En caso de que la memoria RAM supere los 8GB de y la versi´ on de PostgreSQL en ejecuci´ on sea una de 32 bits.La vista pg settings de la base de datos sirve para ver las configuraciones y la funci´ on current setting() puede ser usada para mostrar informaci´ on sobre los par´ ametros.conf. no se aconseja incrementar shared buffers sobre los 2GB debido a que se puede sin memoria virtual. Para saber cu´ al es.conf ) Las principales opciones de configuraci´ on de PostgreSQL est´ an en el archivo postgresql. Por ejemplo: show wal_buffers. 4. al igual que SHOW. por ejemplo: select name. Todos los par´ ametros referidos a memoria son de este tipo.3. En un servidor de producci´ on no es vital pero sirve para aprender como funciona la base de datos con su memoria compartida con el fin de aprender a optimizarlo. uno de los de m´ odulos contrib disponibles con PostgreSQL. postmaster Solo se actualizan reiniciando el servidor. Cache de la Base de Datos El cache de la base de datos es el espacio de memoria donde PostgreSQL almacena los resultados de las consultas m´ as utilizadas. Cada par´ ametro de configuraci´ on tiene un contexto asociado donde puede ser cambiado.current_setting(name) FROM pg_settings WHERE name=’wal_buffers’.unit.4. se consulta a la base de datos.setting.2. pero adem´ as puede ser utilizada en una consulta. 4.context from pg_settings. No pueden ser cambiados sin recompilar el servidor. Al cambiar las configuraciones se puede requerir reiniciar el servidor o recargar el archivo de configuraci´ on. Como regla general se puede establecer que darle un 25 % de la memoria RAM del sistema al par´ ameumero razonable para el cache de la base de datos. Configuraci´ on (postgresql. SELECT name. de tal manera que pueda responder con mayor velocidad a las nuevas consultas que se presenten. Se puede explorar el cache de la Base de Datos utilizando el m´ odulo pg buffercache. Los contextos son los siguientes: internal: Son par´ ametros sobre todo internos establecidos en tiempo de compilaci´ on. 41 .

conf en el servidor. user: Las sesiones individuales pueden ajustar estos par´ ametros en todo momento. shared buffers: define la cantidad de memoria que se comparte a trav´ es de todas las conexiones para guardar las p´ aginas recientemente accedidas. Port: Por defecto es 5432 pero puede ser cambiado por otro. La mayor´ ıa de estos par´ ametros alteran como se ejecutan las consultas.d/postgresql restart Para recargar el archivo postgresql. por defecto es localhost pero se puede indicar una lista de ips o * para indicar todas.conf y todos los cambios hechos a estos par´ ametros estar´ an inmediatamente activos. En ubuntu y otros S. Para reiniciar el servidor se debe reiniciar el servicio. 42 .sighup: Enviar al servidor una se˜ nal HUP va a causar que recargue postgresql.4. postgresql. por lo menos un 25 % de la memoria. es posible para sistemas con poca memoria no permitir tantas conexiones. Se puede tambi´ en enviar una se˜ nal HUP utilizando el comando kill.O. lo cu´ al es muy oneroso en caso de que sea peque˜ na. Se desperdicia memoria compartida.1. Es importante no establecer este par´ ametro muy por encima de lo que se necesita.conf Algunos de los par´ ametros m´ as importantes son: listen addresses: Indica a PostgreSQL que ips escuchar. superuser: Pueden ser modificados por cualquier superusuario en cualquier momento y se activan sin recargar. 4.O de la familia debian se utiliza el siguiente comando: sudo /etc/init. lo cu´ al var´ ıa en cada S. es necesario conectarse como superusuario y ejecutar la funci´ on pg reload conf: postgres=# SELECT pg reload conf(). La mayor´ ıa de par´ ametros en este esquema se refieren a la configuraci´ on de los logs del sistema. max connections: Es el m´ aximo numero de conexiones permitidas. Sus cambios solo impactar´ an en la sesi´ on. backend: Estos par´ ametros son similares a los de sighup excepto que los cambios hechos no van a afectar a las sesiones ejecutandose. ps -eaf — grep ”postgres -D” $ kill -HUP 11185 El anterior comando envia la se˜ nal HUP al servidor postgresql de id 11185. Es deseable que este a un valor alto. Como cada conexi´ on utiliza una peque˜ na cantidad de memoria. Tiene efecto sobre todo en la perfomance de las consultas.

Si se tiene un servidor dedicado este valor debe ser un 50 % de la RAM. caso contrario debe ser m´ as alto. etc. la mitad ser´ ıa una cantidad elevada. Si se pone en on se crea un archivo de logs por d´ ıa. logging collector = off El par´ ametro log line prefix se puede configurar para agregar datos al inicio de toda l´ ınea del log. La configuraci´ on de los logs se realiza en postgresql. la base de datos compara su tama˜ no con el de todos los caches reunidos (propio y del Sistema operativo). por lo que incrementarlo a 16MB es normal actualmente. solo sirve para que la Base de datos compare el tama˜ no de las operaciones a realizar para decidir el curso de acci´ on.effective cache size: Es un estimado de cuanta memoria se espera este disponible en los caches del SO y PostgreSQL. Es una de las maneras m´ as efectivas de incrementar la velocidad del servidor. El archivo de logs generalmente est´ a en /var/log en los sistemas basados en Unix. log destination = ’stderr’: El par´ ametro logging collector si se pone en off significa que no se quiere recoger la salida de errores est´ andar para escribirla en otro sitio. 43 .conf (generalmente localizado en /etc/postgresql en m´ aquinas *nix). joins. la cantidad de memoria de la que se disponga entre otros. Es utilizado por el planificador de consultas para deducir si los planes considerados entrar´ an en la RAM o no. work mem: Controla la cantidad m´ axima de memoria asignada a cada operaci´ on como ordenamiento. maintenance work mem: Es el total de memoria asignada para labores de mantenimiento. Las configuraciones por defecto de logs en postgresql. ALTER TABLE ADD FOREIGN KEY) no necesita m´ as de del 5 % de la RAM. 4. Si est´ a vac´ ıo no se agrega nada. Este par´ ametro no reserva memoria. Configuraci´ on de logs La generaci´ on de Logs es importante debido a que permite conocer las acciones de la BD y los usuarios. La cantidad o ´ptima de memoria depende del tipo de trabajo que se lleve a cabo. Dependiendo del nivel de Logs. effective cache size: Al hacer operaciones que requieren gran uso de memoria.4. En UNIX se calacula sumando los valores de free y cached que se ven en los comandos free o top y sumando adem´ as el valor de shared buffers. La forma gen´ erica de asignarlo es considerar cuanto RAM hay fuera de shared buffers dividida entre max connections y tomar un porcentaje del resultado. CREATE INDEX.2. lo que es 50MB por cada GB de memoria. se va a generar mayor o menor cantidad de informaci´ on que permitir´ a conocer las acciones de la Bd y sus usuarios en un periodo determinado de tiempo. wal buffers: El valor por defecto es de 64KB. lo cu´ al es muy bajo para los tama˜ nos actuales de la RAM. se pueden redirigir hacia un archivo utilizando pg ctl -l al iniciar el servidor. Si el tipo de trabajo es ligero entonces este valor debe ser bajo. Aproximadamente cada proceso de mantenimiento (VACUUM.conf son las siguientes: La opci´ on de configuraci´ on log destination dirige los errores hacia la salida est´ andar.

por lo que el administrador del sistema ser´ a el responsable de hacerlo.log’ El sistema operativo no se encarga del mantenimiento de los logs. Mod: Registra todas las acciones que implican cambio de un valor.%m.log line prefix = ” El par´ ametro log directory indica el directorio donde se crean los logs. %t: Timestamp %u: Database user name %r: Remote host connection is from %d: Database connection is to %p: Process ID of connection Aunque al inicio no se sepa porque se desean estos valores. lo cu´ al en la pr´ actica es todo menos las consultas SELECT. Para hacer los logs de postgreSQL compatibles con pgFouine (una herramienta para analizar logs) se puede utilizar alguna de estas l´ ıneas. log directory = ’pg log’ Y log filename es el formato del nombre de los archivos de logs de Postgresql.%d %H %M %S. de preferencia utilizando alg´ un m´ etodo autom´ atico como un script.db= %d’ log line prefix = ’ %t [ %p]: [ %l-1] user= %u. utilizando fecha y hora. 44 .remote= %r’ log statement Para decidir el detalle del log que se va a guardar se utiliza el par´ ametro de configuraci´ on log statement.db= %d.%Y. All: Toda acci´ on. None: ning´ un log ddl: Solo data definition language como create y drop. log filename = ’postgresql. es en general impr´ actico ya que genera un crecimiento muy r´ apido del tama˜ no del log (he tenido logs que en d´ ıas alcanzaron los 20GB). son muy u ´tiles para rastrear comportamientos. log line prefix = ’ %t [ %p]: [ %l-1]’ log line prefix = ’ %t [ %p]: [ %l-1] user= %u. se le pueden a˜ nadir par´ ametros para que se agreguen al inicio de cada l´ ınea del log. Detalle de cada par´ ametro de configuraci´ on: log line prefix Este par´ ametro de configuraci´ on est´ a vac´ ıo por defecto.

session_id text. Para activar esta funcionalidad. detail text. Por ejemplo. session_line_num bigint. transaction_id bigint. session_start_time timestamp with time zone. message text. error_severity text. Este tipo de logs permiten que se puedan analizar con diversas herramientas e incluso importarlos en la misma BD para llevar a cabo su an´ alisis mediante consultas SQL. log destination = ’csvlog’ logging collector = on Luego de efectuar los cambios. command_tag text. se debe ajustar el destino de los logs y poner en on el colector. muy u ´til para ubicar problemas de perfomance. connection_from text. se puede utilizar la opci´ on de configuraci´ on log min duration statement para registrar solo registrar las acciones que duren m´ as de una cantidad de tiempo medido en milisegundos. Una vez generado un log en csv. process_id integer. Logs en CSV Un formato reciente (presente desde postgreSQL 8. database_name text. se debe reiniciar el servidor y de ah´ ı en adelante los logs se guardaran en archivos . secrea la tabla postgres log con la estructura del csv: CREATE TABLE postgres_log ( log_time timestamp(3) with time zone. user_name text.log min duration statement En caso se desee solo registrar transacciones que est´ en durando m´ as de lo esperado. 45 . virtual_transaction_id text.log.csv en vez de . sql_state_code text. log min duration statement=1000 significa que se registrar´ an las acciones que duren m´ as de un segundo.3) son los logs guardados como archicos csv.

PRIMARY KEY (session_id. query FROM pg_stat_statements ORDER BY total_time DESC. Y se habilita configurando el siguiente par´ ametro en postgresql.conf. internal_query text. pg stat statements: Es un m´ odulo contrib que se instala utilizando: CREATE EXTENSION pg_stat_statements. application_name text. query_pos integer.hint text. location text. Comando sql que muestra el primer y u ´ltimo commit enviado a la BD.max(log_time) FROM postgres_log WHERE command_tag=’COMMIT’. 46 . internal_query_pos integer.csv’ WITH CSV. An´ alisis de Logs Una vez se tienen los logs se necesita analizarlos para conocer la perfomance de nuestra BD. SELECT total_time. Una vez importado se pueden ejecutar queries que lo analicen. context text. query text. como por ejemplo: SELECT min(log_time). la vista pg stat statements se va a llenar con informaci´ on la cu´ al puede ser consultada como cualquier otra vista. Y se importa a la Bd mediante: COPY postgres_log FROM ’/home/postgres/data/pg_log/postgresql-2010-03-28_215404. session_line_num) ). shared preload libraries = ’pg stat statements’ Luego de reiniciar el servidor y ejecutar consultas.

Donde i es el nombre del ´ ındice y v es el campo de la tabla con el que se va a crear el ´ ındice. ya que a partir de ese n´ umero el sistema rechazar´ a nuevas. por lo que su creaci´ on debe estar justificada por importantes mejoras en la velocidad de las consultas. Para crear un ´ ındice en una tabla se ejecuta el siguiente comando: CREATE INDEX i ON t(v). sirven para incrementar la velocidad del ordenamiento de los registros de una tabla.4.5. una consulta puede usar el ´ ındice para determinar que filas son las que busca en vez de examinar cada fila. Incrementar wal buffers a 16 MB. se debe ejecutar varias veces las consultas de tal modo que la data este en cache y as´ ı deje de impactar en la comparaci´ on. Si se desea un subconjunto de los registros de la tabla.1.5. Establecer maintenance work mem a un valor de 50MB por cada GB de RAM.O entre max connections y luego entre dos.6. 47 . Los ´ ındices ayudan a la base de datos a disminuir la cantidad de data que necesita procesar para ejecutar una consulta. Configuraci´ on de un nuevo servidor La optimizaci´ on inicial de un servidor puede ser un proceso mec´ anico: Ajustar los logs para ser m´ as verbosos. ´ Indices Un ´ ındice es una lista organizada de valores que aparece en una o m´ as columnas de una tabla. las consultas posteriores van a ser m´ as r´ apidas debido a que los resultados est´ an en la cache de la base de datos. Efectos del cache de la BD Es importante resaltar que cuando se ejecuta una consulta varias veces. Para eliminar el efecto del cache al probar varias consultas con un mismo fin. Utilizar un 25 % para shared buffers. Estimar generosamente el m´ aximo n´ umero de conexiones. Iniciar el servidor y asignar effective cache size sumando shared buffers y la cache del Sistema Operativo. debido a que un ´ ındice tiene un orden. 4. 4. Calcular work mem dividiendo el cache del S. Los ´ ındices pueden ser muy grandes y su mantenimiento ser costoso en recursos para la base de datos. Adem´ as. Mediante EXPLAIN ANALYZE se puede hallar si fue u ´til o no la creaci´ on del ´ ındice.

48 . autom´ aticamente se le crea un UNIQUE INDEX para asegurar que todos sus valores sean u ´nicos.Cuando un campo es definido como Primary Key al ser creada la tabla. Para que no se acepten valores nulos es una buena pr´ actica agregar NOT NULL al campo.

6. Determinar que sistema de archivos ser´ a mejor para su servidor. Determinar si su servidor necesita m´ as RAM. Haga lo mismo para un UPDATE y un INSERT. 4. 3. 8. 49 . Ejecute un SELECT sobre una tabla y analice su plan. 7. Determinar si su servidor necesita m´ as n´ ucleos o n´ ucleos m´ as potentes. 5. 2. Calcular el tama˜ no ideal de su par´ ametro work mem. Calcular el tama˜ no ideal de su par´ ametro shared buffers. Calcular el tama˜ no ideal de su par´ ametro effective cache size.Ejercicios: 1.

sql -d dellstore2” sudo su postgres -c “psql -d dellstore2 -c “VACUUM VERBOSE ANALYZE”” Para conocer el tama˜ no de la base de datos ejecutar: SELECT pg_size_pretty(pg_database_size(’dellstore2’)).Cap´ ıtulo 5 Ajustes de rendimiento II: Optimizaci´ on de las Bases de datos Para algunos administradores de Bases de datos y desarrolladores. Los clientes dan o ´rdenes de compra.org/projects/dbsamples/. cada una de las cu´ ales referencia productos siendo comprados. 50 .gz tar xvfz dellstore2-normal-1. Se puede descargar de http://pgfoundry. Data de ejemplo Para optimizar consultas.0.gz cd dellstore2-normal-1.0/ sudo su postgres -c“createdb dellstore2” sudo su postgres -c “psql -f dellstore2-normal-1. a menos que se indique lo contrario. Los ejemplos en este cap´ ıtulo se dar´ an a partir de Dell Store 2. La tienda tiene clientes. optimizar las consultas es la parte m´ as importante de la optimizaci´ on de una base de datos.php/543/dellstore2-normal-1.1. Cada orden tiene un n´ umero de l´ ıneas.0.tar. 5.0.tar. originalmente creata por Dell y luego portada a PostgreSQL. cada uno de los cu´ ales entra en una categor´ ıa. [5] La estructura de la data es sencilla: Hay un n´ umero de productos que la tiendas vende. para lo cual se utilizar´ a la base de datos Dell Store 2. se necesita data que analizar.org/frs/download. $ $ $ $ $ $ wget http://pgfoundry.

Por ejemplo. si se ejecuta: EXPLAIN ANALYZE DELETE * FROM t. la segunda vez va a ejecutarse m´ as r´ apido. Explain y Explain Analyze Para conocer el porque de velocidad de ejecuci´ on de una consulta se utiliza el comando EXPLAIN antes de la consulta lo cual muestra el resultado esperado de dicha consulta o query plan (plan de la consulta).2. significa que su data en la cache se ha estabilizado y ya no indice en el resultado. Timing Para conocer cuanto demora en ejecutarse una consulta se utiliza el comando timing antes de ejecutar la consulta de tal manera que mida el tiempo requerido.Una historia de cliente es salvada listando todos los productos que el cliente alguna vez ha ordenado.3. 5. dellstore2=# \timing dellstore2=# SELECT count(*) FROM customers. 5. Las consultas y la cache Cuando la data necesaria para responder a una consulta est´ a en la cache de la base de datos o del sistema operativo. 5. No solo se va a obtener el plan sino efectivamente se va a eliminar todo el contenido de la tabla t. la consulta se lleva a cabo m´ as r´ apido debido a que ya no se necesita recuperar la data del disco. Si se utiliza EXPLAIN ANALYZE se obtiene la estimaci´ on describiendo lo que espera el planificador de PostgreSQL y adem´ as lo que realmente sucede despu´ es de ejecutar la consulta. Cuando la consulta empieza a ejecutarse siempre con la misma duraci´ on.245 ms Para desactivar volver a escribir \timing.4. Si se ejecuta dos veces una consulta. solo obtenerla de la memoria. count ------20000 Time: 9. [5] 51 .

52 . count ------20000 (1 fila) Como se puede apreciar.d/postgresql start Se ejecuta la consulta: $ psql -d dellstore2 \timing SELECT count(*) FROM customers. Efecto de la cache Para identificar el impacto de la cache.1. Estructura del plan de la consulta La salida del comando EXPLAIN est´ a organizada en una serie de nodos.276 ms SELECT count(*) FROM customers. se va a limpiar la cache del sistema y luego se volver´ a a ejecutar la consulta: Limpiar la cache: $ sudo /etc/init. Cada l´ ınea de la salida es un nodo.4. Para eliminar el efecto de la cache sobre una consulta.5.d/postgresql stop $ sudo su # sync # echo 3 ¿/proc/sys/vm/drop caches # exit $ sudo /etc/init.2. Al m´ as bajo nivel est´ an los nodos que analizan tablas e ´ ındices. Los nodos de m´ as alto nivel cogen la salida de los nodos de bajo nivel y operan sobre esta.4. 5. count ------20000 (1 fila) Duracion: 350. la cache influencia en gran medida el rendimiento de las consultas en el sistema. esta debe ser ejecutada varias veces hasta que sus tiempo de ejecuci´ on sean similares.

00: El primer costo es el costo de iniciar el nodo.00. Esto es cuanto trabajo es estimado antes de que este nodo produzca su primera fila de salida. En casos de querys m´ as complejos la sobrecarga producida por el an´ alisis es menor..489: El actual costo de inicio no fue cero. El resto de par´ ametros son relativos a este cuyo valor es 1. En este caso es 0 ya que una b´ usqueda secuencial devuelve resultados de forma inmediata. 5. se ejecutan m´ as de una vez. 53 . se necesito una peque˜ na fracci´ on de tiempo para empezar.00.27. a´ un as´ ı no se debe de confiar completamente en los tiempo producidos por EXPLAIN ANALYZE. rows=20000: El n´ umero de filas que este nodo espera como salida.489 segundos para terminar.4.676.676.00 rows=20000 width=268) (actual time=0.010. width=268 : El n´ umero esperado de bytes de cada fila de la salida.0. cpu tuple cost: Cuanto cuesta procesar un solo registro. Este plan tiene un nodo.3.451 ms (2 filas) Al ejecutarse con EXPLAIN ANALYZE la duraci´ on aumenta varias veces.011. El segundo n´ umero es el costo estimado de ejecutar todo el nodo hasta que termine. Los n´ umeros actuales muestran como realmente se llevo a cabo la consulta: actual time=0. random page cost: El costo de lectura cuando los registros est´ an dispersos por varias p´ aginas. Costo de computaci´ on La labor b´ asica del optimizador de consultas es generar planes que puedan utilizarse para ejecutar una consulta y escoger el que tenga el menor costo de ejecuci´ on. Rows=20000: Tal como se esperaba fueron 20000 filas.34.434 rows=20000 loops=1) Total runtime: 52. un nodo Seq Scan cost=0. El valor por defecto es 4.0. loops=1: Algunos nodos. como los que hacen joins. QUERY PLAN -----------------------------------------------------------------------------------------Seq Scan on customers (cost=0. Una vez que empez´ o necesito 34.. En ese caso el valor de loops va a ser m´ as de uno y el tiempo y la cantidad de filas van a ser referidas a cada loop no al total.. El costo es hecho de forma arbitraria..1.Por ejemplo: # EXPLAIN ANALYZE SELECT * FROM customers. seq page cost: Cuanto demora leer una sola p´ agina desde el disco en forma secuencial. su valor por defecto 0.

01 0.0 4. current_setting(’seq_page_cost’) AS seq_page_cost. current_setting(’cpu_tuple_cost’) AS cpu_tuple_cost. cpu operator cost: El costo esperado de procesar una funci´ on o un operador (la suma de dos n´ umeros por ejemplo) y por defecto es 0. Se pueden combinar los costos internos utilizados por PostgreSQL con las estad´ ısticas utilizadas por el optimizador.01 | 200 54 . relpages * current_setting(’seq_page_cost’)::decimal AS page_cost.conf.0025. Se puede comparar en una tabla: Par´ ametro seq page cost random page cost cpu tuple cost cpu index tuple cost cpu operator cost Valor por Defecto 1. El valor por defecto es 0. SELECT relpages. reltuples. menor de lo que cuesta procesar un registro debido a que los registros tienen mucha m´ as informaci´ on de cabecera (como xmin y xmax ). Se obtiene: relpages | seq_page_cost | page_cost | reltuples | cpu_tuple_cost | tuple_cost ----------+---------------+-----------+-----------+----------------+-----------476 | 1 | 476 | 20000 | 0.0025 Velocidad relativa Reference 4X slower 100X faster 200X faster 400X faster Todos estos valores se pueden encontrar en postgresql.005 0. Se pueden utilizar estos n´ umeros para calcular el costo mostrado en el ejemplo previo.005. Una b´ usqueda secuencial de la tabla “customers” debe leer cada p´ agina en la tabla y procesar cada registro.0 0. reltuples * current_setting(’cpu_tuple_cost’)::decimal AS tuple_cost FROM pg_class WHERE relname=’customers’.cpu index tuple cost: El costo de procesar una sola entrada de un ´ ındice.

Tambi´ en sirve para distinguir entre registros id´ enticos.5.1)’::tid) ´ Indices Cuando se ejecutan consultas que incluyen LIMIT es u ´til buscar mediante un campo que este indexado. 5.1. Se puede utilizar en una misma transacci´ on para referirse a un registro que se repite varias veces y as´ ı acelerar su b´ usqueda. Armando conjuntos de registros Para optimizar la selecci´ on de los registros buscados por una consulta se pueden tomar en cuenta diversas optimizaciones. el que se puede ver en la columna ctid. 5. debido a que un elevado porcentaje de las p´ aginas est´ a en la cache y es encontrada con mayor facilidad que en el disco. una configuraci´ on com´ un cuando se sabe que gran parte de la base de datos puede entrar en la memoria es reducir random page cost a 2. el costo mostrado por EXPLAIN.4.1)’. No es u ´til en diferentes transacciones ya que puede cambiar con una actualizaci´ on. Para saber que columnas se est´ an utilizando en una consulta. Un ejemplo de ctid: EXPLAIN SELECT customerid FROM customers WHERE ctid=’(0..00. 55 . Los par´ ametros de costo se pueden configurar.Agregar el costo de leer la p´ agina (page cost ) al costo de procesar los registros (tuple cost ) y se obtiene 676.5. QUERY PLAN --------------------------------------------------------Tid Scan on customers (cost=0. Id de los registros Todo registro tiene un Id. se puede utilizar el modo verboso: EXPLAIN VERBOSE SELECT * FROM customers. ya que as´ ı el ordenamiento ser´ a m´ as r´ apido. Optimizaci´ on de consultas Para optimizar las consultas en primer lugar se explicar´ a como mejorar el rendimiento de la obtenci´ on de los registros y luego de las operaciones con los registros. por ejemplo al eliminar registros duplicados.01 rows=1 width=4) TID Cond: (ctid = ’(0.

676.77 rows=20000 width=8) (actual time=62. En el ejemplo podemos ver que a pesar de la peque˜ na cantidad de data (352kB) esta ha sido calculada en el disco. el siguiente tipo de nodo que se va a encontrar cuando se usa una sola tabla son aquellos que procesan el conjunto de varias formas.00 rows=20000 width=8) Seq Scan on customers (actual time=0.5. Si el par´ ametro work mem es incrementado.639 rows=20000 loops=1) Sort Key: zip Sort Method: quicksort -> Memory: 1294kB (cost=0. QUERY PLAN ----------------------------------------------------------------------Sort (cost=2104. el algoritmo quicksort (utilizado en la memoria) necesita m´ as memoria que la utilizada en el disco duro al combinar archivos previamente ordenados..101. EXPLAIN ANALYZE SELECT customerid FROM customers ORDER BY zip. [5] SET work_mem=’2MB’.513.2..Sort Nodos de ordenamiento aparecen cuando se utiliza ORDER BY en las consultas: EXPLAIN ANALYZE SELECT customerid FROM customers ORDER BY zip.87.33....299. Ordenamiento .676.2154.31.00.00 rows=20000 width=8) (actual time=0.2154.015. Procesando los nodos Una vez que se tiene un conjunto de registros.845 rows=20000 loops=1) 56 .. la operaci´ on se lleva a cabo en memoria.266 rows=20000 loops=1) Total runtime: 126.535 ms Las operaciones de ordenamiento se pueden ejecutar en memoria (m´ as r´ apido) o en disco (m´ as lento).77 rows=20000 width=8) (actual time=74.5.232 rows=20000 loops=1) Sort Key: zip Sort Method: external sort -> Seq Scan on customers Disk: 352kB (cost=0.77.013..77.00. Estos nodos por lo general cogen un conjunto de registros y devuelven otro. QUERY PLAN ----------------------------------------------------------------------------Sort (cost=2104.. A´ un cuando es menor que el valor por defecto de work mem (1MB).

Para calcular una funci´ on de agregaci´ on. QUERY PLAN -----------------------------------------------------------------------Aggregate (cost=726. MIN().534. al utilizar ´ ındices el tiempo disminuye considerablemente: EXPLAIN ANALYZE SELECT max(customerid) FROM customers.. EVERY().56.066 rows=1 loops=1) InitPlan 1 (returns $0) -> Limit (cost=0...01 rows=1 width=4) (actual time=56.726.. Algunos ejmeplos son AVG().0.054..00.00.049 rows=1 loops=1) Index Cond: (customerid IS NOT NULL) Heap Fetches: 0 57 ..26.. se leen todos los registros y luego se pasan por por el nodo agregado para calcular el resultado: EXPLAIN ANALYZE SELECT max(zip) FROM customers..Total runtime: 112.056 rows=1 loops=1) -> Index Only Scan Backward using customers_pkey on customers (cost=0.00 rows=20000 width=4) (actual time=0.588 ms Se puede apreciar que el valor por defecto no era suficiente y se necesitaba aumentar work mem para que la operaci´ on se llevara a cabo en la memoria.04 rows=1 width=0) (actual time=0..25 rows=20000 width=4) (actual time=0.0.127.203 ms No siempre este el caso.128 rows=1 loops=1) -> Seq Scan on customers (cost=0.676.00.958 rows=20000 loops=1) Total runtime: 56.0. QUERY PLAN ---------------------------------------------------------------------Result (cost=0. MAX().00.049. Funciones de agregaci´ on .03 rows=1 width=4) (actual time=0.Aggregate Las funciones de agregaci´ on reciben una serie de valores y producen una sola salida. COUNT().0.0. STDDEV() y SUM()..03.011.064.

. multiplicando de forma anidada cada registro por toda la otra tabla.00. el n´ umero de posibilidades crece de forma dram´ atica.00 rows=20000 width=268) (actual time=9..00 rows=10000 width=49) (actual time=8. EXPLAIN ANALYZE SELECT * FROM products.694 rows=10000 loops=20000) -> Seq Scan on products (cost=0. Si solo son tres tablas.676.12.248.Total runtime: 0. QUERY PLAN -------------------------------------------------------------------------Nested Loop (cost=0.5...120 ms $ 5. [5] En un CROSS JOIN se multiplican todos los registros de una tabla por los de otra. Si existe un ´ ındice en una de las tablas.00 rows=10000 width=49) (actual time=0.979 ms Bucle anidado con b´ usqueda mediante ´ ındices Lo m´ as com´ un en un bucle anidado donde una tabla solo est´ a devolviendo un n´ umero limitado de registros.243 rows=20000 loops=1) -> Materialize (cost=0.customers.102.394.3.00.791143. Joins Las tareas m´ as complejas del planificador de consultas son las que tienen que ver con unir tablas entre si. pero si son veinte tablas... el planificar considerar´ a todo posible plan para seleccionar el ´ optimo. Cada vez que se agrega una tabla al conjunto que se le aplicar´ a join.2500899..00. el optimizador lo utilizar´ a para limitar el n´ umero de registros y hacer el tiempo de ejecuci´ on menor.00. la cantidad de posibilidades es muy grande para considerarlas todas. 58 .013 rows=10000 loops=1) Total runtime: 1029182. En pseudoc´ odigo: for each outer row: for each inner row: if join condition is true: output combined row Se puede observar algo similar en data real si es que se unen dos tablas sin un WHERE de por medio.955 rows=200000000 loops=1) -> Seq Scan on customers (cost=0.198.411..00 rows=200000000 width=317) (actual time=17.002.25.844.

00.00..259.orderid.048..66 rows=5 width=48) (actual time=0.011.0..012.27 rows=1 width=30) (actual time=0.316 rows=1 loops=1) Filter: (totalamount = 329.047.026.070.025 rows=6 loops=1) 59 . QUERY PLAN -----------------------------------------------------------------------------Nested Loop (cost=0..00..orderlines WHERE orderlines. EXPLAIN ANALYZE SELECT * FROM orders.41 rows=5 width=48) (actual time=0.8.36 rows=5 width=18) (actual time=0..orderlines WHERE orders.78 AND orders...0.0.orderid.00 rows=1 width=30) (actual time=0.. orderid=1000 AND orders.00.34 rows=5 width=18) (actual time=0.15.029 rows=1 loops=1) Index Cond: (orderid = 1000) -> Index Scan using ix_orderlines_orderid on orderlines (cost=0.472 ms En caso de que ambas tablas utilicen un ´ ındice la consulta es a´ un m´ as r´ apida: EXPLAIN ANALYZE SELECT * FROM orders. QUERY PLAN ----------------------------------------------------------------------Nested Loop (cost=0.Considerar el caso donde se est´ a buscando una sola orden utilizando un campo sin ´ ındice (por lo que la b´ usqueda debe ser secuencial) pero haciendo un join con su respectiva orden de compra.78) Rows Removed by Filter: 11999 -> Index Scan using ix_orderlines_orderid on orderlines (cost=0.orderid=orderlines.totalamount=329.387 rows=9 loops=1) -> Seq Scan on orders (cost=0.23.029 rows=9 loops=1) Index Cond: (orderid = orders.15.244...00.8.087 rows=6 loops=1) -> Index Scan using orders_pkey on orders (cost=0.00..0.orderid) Total runtime: 8.8.orderid=orderlines.

03.484..144 rows=8996 loops=1) -> Merge Join (cost=0..25 rows=20000 width=4) (actual time=28.443.customerid.1536.021.176.customerid=O. Para optimizar esta consulta es u ´til no hacer el join con campos cuyas columnas tengan tablas repetidas.customerid = o.sum(netamount) FROM customers C.1356..173 ms Merge Join Este tipo de join requiere que ambas entradas esten ordenadas.Index Cond: (orderid = 1000) Total runtime: 0. luego busca a trav´ es de las dos en orden moviendose un registro a la vez a trav´ es de las tablas mientras los valores las columnas utilizadas para el join cambian..420.49 rows=12000 width=10) (actual time=28.49 rows=12000 width=10) (actual time=28.03. Luego el ejecutor puede utilizar un Merge Join de forma eficiente para combinar ambos.25.142..00.customerid GROUP BY C...00.customerid) -> Index Only Scan using customers_pkey on customers c (cost=0. 60 . Para ver un merge join se necesita una condici´ on de igualdad como la mostrada en un reporte donde se indica cuanto ha comprado cada cliente: EXPLAIN ANALYZE SELECT C.672.058 ms La consulta se realiza siguiendo los ´ ındices de customerid tanto en customers como en orders para encajar ambas tablas entre si de forma ordenada. Una tabla puede ser revisada varias veces si la tabla por la que se busca tiene valores repetidos.customerid.. orders O WHERE C. QUERY PLAN ----------------------------------------------------------------GroupAggregate (cost=0.228 rows=12000 loops=1) Total runtime: 187.358.24 rows=12000 width=10) (actual time=0.956 rows=20000 loops=1) Heap Fetches: 0 -> Index Scan using ix_order_custid on orders o (cost=0.030 rows=12000 loops=1) Merge Cond: (c.56.

Una consulta para encontrar los productos que en alg´ un punto han sido ordenados por cualquier cliente muestra un Hash Join.008. los Hash Joins requieren memoria para guardar todos los registros.5.prod_id). 5.73...152 rows=60350 loops=1) Total runtime: 272.163 rows=10000 loops=1) -> Hash (cost=1206.202.73 rows=9736 width=4) (actual time=187.643 ms Dependiendo del tipo de entrada puede ser mejro o peor que Merge Join. Adem´ as.216.38..953..593 rows=9973 loops=1) Hash Cond: (p.4. Este tipo de join es utilizado sobre todo cuando una de las tablas es peque˜ na y construir la tabla hash es poco costoso. Este tipo de Join no ordena sus entradas.50 rows=60350 width=4) (actual time=0.1773.80 rows=9736 width=19) (actual time=216.00. lo cu´ al puede requerir que se amplie el par´ ametro work mem..958.260.. La salida no necesariamente va a estar en orden.345 rows=9973 loops=1) -> Seq Scan on orderlines ol (cost=0....436 rows=9973 loops=1) Buckets: 1024 -> Batches: 1 Memory Usage: 234kB HashAggregate (cost=1109. Si la entrada no est´ a ordenada puede ser mejor que el Merge Join. QUERY PLAN -----------------------------------------------------------------Hash Join (cost=1328. crea una tabla Hash para cada registro de una tabla con los registros correspondientes de la otra tabla.478. controlar la complejidad se vuelve m´ as importante para optimizar las consultas y el rendimiento de PostgreSQL..prod_id=p.00.73 rows=9736 width=4) (actual time=216.00 rows=10000 width=19) (actual time=0. 61 .prod_id = ol. en vez de eso.Hash Join La principal alternativa utilizada por PostgreSQL para un Merge Join es un Hash Join.prod_id) -> Seq Scan on products p (cost=0.436. Ordenamiento de Joins A medida que se incrementa el n´ umero de joins y la cantidad de registros.43.198.title FROM products p WHERE EXISTS (SELECT 1 FROM orderlines ol WHERE ol.1206. EXPLAIN ANALYZE SELECT prod_id.13.008.91.1206.

QUERY PLAN -------------------------------------------------------------------- 62 .customerid=c. por ejemplo: EXPLAIN ANALYZE SELECT products.prod_id.customerid=c.prod_id=p.customerid=c. SET join_collapse_limit = 1. Por ejemplo el siguiente es un LEFT JOIN que lista productos con su inventario. Esta consulta es igual a una realizada utilizando joins impl´ ıcitos: SELECT * FROM cust_hist h.customerid). En ambos casos el planificador puede elegir planes que ejecuten primero los joins entre cust hist y products o entre products y customers. SELECT * FROM cust_hist h INNER JOIN products p ON (h.Forzar el orden de los joins Se puede forzar a que el planificar de PostgreSQL utilice el orden de querys establecido en una consulta.prod_id=inventory.customers c WHERE h. una consulta que utiliza joins de forma expl´ ıcita: SELECT * FROM cust_hist h INNER JOIN products p ON (h.customerid).prod_ id AND h. De esta forma la consulta empezar´ a por cust hist.products p.prod_id) INNER JOIN customers c ON (h.customerid. Por ejemplo. Pero algunas consultas no necesitan el JOIN. puede indicarlo a PostgreSQL de tal forma que no pierda tiempo buscando un plan.prod_id=p.prod_id=inventory.prod_id=p. SELECT * FROM products LEFT JOIN inventory ON products. Eliminar Joins Una funcionalidad de PostgreSQL es la de eliminar Joins (Left o Right) innecesarios.prod_id) INNER JOIN customers c ON (h.prod_id. En caso de que el desarrollador sepa que hay una manera eficiente de hacer el join.title FROM products LEFT JOIN inventory ON products. Para impedir que se reordene la consulta. establecer el par´ ametro a 1. seguir´ a por products y terminar´ a en customers. Para hacerlo se debe reducir el par´ ametro join collapse limit de su valor por defecto de 8.

. PostgreSQL los eliminar´ a para optimizar la consulta.777 ms Debido a que es un LEFT JOIN y la consulta solo busca valores de la tabla products.198.5. si por alg´ un motivo se quisiera hacer que todos los clientes fueran de Maryland. se deben utilizar.00. Rides AS R1 WHERE S1. Usar expresiones simples En lo posible evitar los JOINS en favor de argumentos simples de b´ usqueda. se efectuar´ ıa la siguiente consulta: UPDATE customers SET state=’MD’ WHERE NOT state=’MD’.15.5. Este hecho puede ser poco importante en consultas simples.town = R1..town = ’Atlanta’ 63 . 5. Puede ser simplificada a: SELECT * FROM Students AS S1. pero en estructuras m´ as complicadas con vistas y consultas generadas autom´ aticamente es posible que sea una mejora significativa. Por ejemplo. existen diversos consejos y reglas pr´ acticas que pueden ayudar a hacerlas m´ as eficientes.Seq Scan on products (cost=0. La condici´ on colocada impide la redundancia de volver a escribir donde el estado ya fuera Maryland. Rides AS R1 WHERE S1.town = ’Atlanta’.town AND S1. Debido a esta funcionalidad. Tips para optimizar SQL Para escribir consultas SQL.694 rows=10000 loops=1) Total runtime: 28.00 rows=10000 width=19) (actual time=0. ya que en caso no sean necesarios. UPDATES Para realizar actualizaciones de forma o ´ptima. se debe especificar con claridad en la cl´ ausula WHERE a que registros afectar. no es necesario el JOIN y por lo tanto PostgreSQL lo deja de lado.014. por ejemplo una consulta como la siguiente: SELECT * FROM Students AS S1. si se puede utilizar LEFT O RIGHT JOIN.

Esta consulta probablemente va a utilizar una estrategia de combinar los ´ ındices.code = O1. Asumiendo que hubieran diez estudiantes de cien que fueran para Atlanta y cinco de cien ofrecieran viajes a Atlanta. se tendr´ ıan 100 * 100 = 10000 registros en el CROSS JOIN. Esta consulta va a correr m´ as lento que la siguiente: SELECT * FROM Students WHERE grade = ’A’ AND sex = ’female’. Debido a que hay menos estudiantes con nota A que estudiantes mujeres. una m´ as grande para ordenes y otra m´ as peque˜ na que traduce un c´ odigo a ingl´ es.AND S1. colocar las m´ as restrictivas primero.town = ’Atlanta’. La segunda versi´ on asegura que de ambas tablas se va a utilizar la menor cantidad de registros por lo que el JOIN no va a ser costoso. SELECT * FROM Orders AS O1. 64 . se tendria una tabla de diez registros y otra tabla de cinco registros para el CROSS JOIN. Otra aplicaci´ on del mismo concepto es un truco con predicados que involucran dos columnas para forzar la elecci´ on del ´ ındice a ser utilizado. Por ejemplo. Colocar la tabla con el menor n´ umero de registros al final de la cl´ ausula FROM y colocar la expresi´ on que la utiliza al inicio de la cl´ ausula WHERE. pero si se utiliza una expresi´ on sin efecto se puede forzar a PostgreSQL a utilizar el ´ ındice de la tabla m´ as peque˜ na. En la segunda versi´ on. considerar dos tablas. cada una con un ´ ındice en la columna JOIN.code. si el JOIN se ejecutara primero. Por ejemplo: SELECT * FROM Students WHERE sex = ’female’ AND grade = ’A’. Otra regla pr´ actica es que cuando se tiene un conjunto de condiciones unidas por un AND. Codes AS C1 WHERE C1.

Por ejemplo: SELECT * FROM Sales WHERE alphacode IS NOT NULL. Si se asume que todos los c´ odigos son mayores a 00.code = O1. Otro truco es evitar el predicado IS NOT NULL y utilizar un valor constante m´ ınimo en su reemplazo.ordertype >= ’00’ AND C1. Otra t´ ecnica es utilizar COUNT() con un ´ ındice para hacer m´ as r´ apida la respuesta. se necesita que tenga un ´ ındice en el campo ’religion’. por lo que el motor debe hacer m´ as trabajo. entonces la primera condici´ on siempre es cierta y se va a utilizar el ´ ındice en Orders. Los NULLS son guardados en diferente espacio f´ ısico que sus columnas.SELECT * FROM Orders AS O1. El operador <> tiene algunos problemas. Puede ser escrito de man era que evite las lecturas extra: SELECT * FROM Sales WHERE alphacode >= ’AAA’. Para que la segunda versi´ on sea m´ as veloz. Por ejemplo: 65 . Para romper la condici´ on se puede utilizar: SELECT * FROM Ireland WHERE religion < ’Catholic’ OR religion > ’Catholic’. El optimizador puede preferir una b´ usqueda secuencial y no usar un ´ ındice. Codes AS C1 WHERE O1.code. Por ejemplo: SELECT * FROM Ireland WHERE religion <> ’Catholic’.

common.SELECT COUNT(invoice_nbr) FROM Sales. Pero se le entregar´ ıa mas informaci´ on al planificador para que decida que tabla es m´ as peque˜ na y empezar por esta. Table3 WHERE Table1. dada una consulta que busca las tareas que demoran tres d´ ıas de completar en 1994: 66 . Evitar expresiones matem´ aticas en columnas con ´ ındices Si una columna aparece en una expresi´ on matem´ atica.common = Table3. Por ejemplo. El motor de base de datos no tiene estad´ ısticas acerca de la relativa frecuencia de los valores en una lista de constantes por lo que asumir´ a que la lista estar´ a en el orden en que ser´ a utilizada por lo que es mejor ordenar una lista de los valores m´ as utilizados a los menos utilizados.common = Table1. Table2.common = Table2.common AND Table3. Entregar informaci´ on extra a las consultas Un gestor de base de datos no siempre va a llegar a la misma conclusi´ on. Adem´ as. Por ejemplo. SELECT * FROM Table1. ya que solose elegir´ a uno.common AND Table3.common = Table3. para usar JOIN en tres tablas diferentes sobre una misma columna se puede escribir: SELECT * FROM Table1. el gestor no podr´ a utilizar sus ´ ındices. tampoco tiene sentido utilizar valores duplicados en una lista de constantes.common.common = Table1. El predicado IN Hay dos formas para uitlizar el IN. Table2. Es m´ as veloz que la versi´ on COUNT(*) si invoice nbr es una llave primaria u otra columna con ´ ındice. Table3 WHERE Table2. a m´ as informaci´ on en la consulta mayor opci´ on a que el planificador encuentre un mejar plan. el primero que se encuentre.common AND Table2. pasar una lista expl´ ıcita de valores o una subconsulta que genere esta lista de valores.

SELECT task_nbr FROM Tasks WHERE (finish_date . si se quiere hallar los estudiantes que estudian ciencia: SELECT DISTINCT S1. PostgreSQL lo convertir´ a en un SELECT simple.name FROM Students AS S1. Pero si se tiene un ´ ındice en la columna finish date (debido a lo frecuente de su uso) no se estar´ ıa utilizando.start_date) = INTERVAL ’3’ DAY AND start_date >= CAST (’2005-01-01’ AS DATE).dept. Esta consulta puede ser reemplazada por: SELECT S1.name FROM Students AS S1 WHERE EXISTS (SELECT * FROM ScienceDepts AS D1 WHERE S1.dept = D1. Sin embargo. Evitar el ordenamiento En lo posible evitar operaciones de ordenamiento como SELECT DISTINCT y ORDER BY. su hay columnas mcon valores u ´nicos como un primary key. [1] Se puede reemplazar un SELECT DISTINCT con un EXIST(). por lo que la siguiente consulta se ejecutar´ ıa m´ as r´ apido: SELECT task_nbr FROM Tasks WHERE finish_date = (start_date + INTERVAL ’3’ DAY) AND start_date >= CAST (’2005-01-01’ AS DATE). ScienceDepts AS D1 WHERE S1. 67 .dept). En el caso de DISTINCT. por ejemplo.dept = D1. la primera consulta puede ser buena para columnas en tablas peque˜ nas en las que solo se requiera b´ usqueda secuencial.

effective cache size El valor por defecto es 128MB y es un par´ ametro utilizado para representar cuanta espacio de cache hay para la base de datos. 5. siendo la alternativa una b´ usqueda secuencial. 5. asignarles valores m´ as optimistas.5. con alta probabilidad de que sus resultados ya esten en memoria. Optimizando las consultas para la data en cache PostgreSQL asume que la data no est´ a en cache al hacer el planeamiento de una consulta por lo ´ que todo acceso a un Indice o una tabla requerir´ a acceso a disco. Comprobar la equivalencia de un query En caso se haya escrito una consulta que se considera equivalente a otra pero m´ as r´ apida. Lo u ´nico para lo que se utiliza es para estimar cuando un ´ Indice va a entrar en memoria. se pueden tener valores conservadores como valor por defecto y solo a las consultas m´ as frecuentes.1. se pueden volver m´ as optimistas los par´ ametros del planificador. Generalmente es m´ as de la mitad de la memoria RAM en un servidor dedicado. Par´ ametros para el planeamiento de consultas Algunos par´ ametros pueden ser establecidos en una transacci´ on para ayudar a mejorar el rendimiento.3. Si la data que se va a leer se espera que este en cache.6. as efectivo definirlo para las grandes transacciones y dejar un Para utilizar effective cache size es m´ valor conservador por defecto. asignandole Al igual que effective cache size.7. para comprobar si dos consultas son equivalentes se utiliza EXCEPT para ver que registros devueltos por la 68 .6. incluso iguales a cpu index tuple cost. SET random_page_cost=0. work mem ametro puede ser definido por cada transacci´ on. este par´ valores grandes para las transacciones que lo requieran y un valor conservador por defecto. Otras consultas donde este par´ ametro influye son los CROSS ´ JOINS que utilizan un Indice. 5. haciendolos m´ as cercanos al costo de acceder al nodo de un ´ ındice (cpu index tuple cost ). 5. Los par´ ametros del planificador seq page cost y random page cost reflejan este pesimismo. Este par´ ametro no reserva memoria solo sirve como un valor de referencia para el planificador sobre la capacidad disponible. Dado que ambos par´ ameros pueden ser establecidos en cada transacci´ on.005.6.6.005. SET seq_page_cost=0.2.

presionar F7.prod_id) EXCEPT SELECT prod_id FROM inventory WHERE sales=0. PgAdmin.8. Proporciona un sustituto f´ acil de leer e interpretar que puede ser utilizado en conjunto con la salida de texto de EXPLAIN ANALYZE. 2. 3. 5. posee la capacidad de explicar de forma gr´ afica los resultados de EXPLAIN ANALYZE. EXPLAIN ANALYZE gr´ afico El administrador gr´ afico de PostgreSQL. Gr´ afico 5. Hacer click en el ´ ıcono de SQL. Escribir una consulta. Abrir PgAdmin.1: EXPLAIN ANALYZE gr´ afico en PgAdmin 69 . Por ejemplo: SELECT prod_id FROM products p WHERE NOT EXISTS (SELECT 1 FROM orderlines ol WHERE ol. 4. Para utilizar esta funcionalidad: 1.prod_id=p.primera consulta no son devueltos por la segunda.

Ejecutar las consultas relativas a dellstore2 en el analizador visual de PgAdmin. 70 .Ejercicios 1.

Write Ahead Log (WAL): Es el log que registra todas las transacciones. Si el servidor principal se cae se espera que otro asuma de inmediato su rol. Debido al gran tama˜ no de muchas bases de datos no se puede esperar copiar la data en el acto. Esclavo: Un servidor esclavo es aquel donde se copia la data.1. Esto es u ´til en el caso de servidores distantes donde la latencia de la red es una dificultad. en cambio se debe tener replicado el servidor. As´ ıncrono: Una transacci´ on en el maestro se va a realizar as´ ı los esclavos no se hayan actualizado.Cap´ ıtulo 6 Alta disponibilidad y replicaci´ on En ocasiones. 6. pero en esencia son dos las m´ as importantes: Disponibilidad y escalabilidad. La escalabilidad significa que agregando servidores se pueda incrementar el n´ umero de accesos a la base de datos sin por eso perjudicar el rendimiento. cuando se busca mejorar el rendimiento de una Base de Datos. 71 . 6. PostgreSQL solo soporta esclavos de solo lectura. una vez que los accceden solo necesitan ejecutar las transacciones en si mismos. La desventaja es que la data en el esclavo puede quedar desactualizada.1. Replicaci´ on Se pueden enumerar diversas razones por las cu´ ales replicar la data. S´ ıncrono: Una transacci´ on en el maestro no se considera completa hasta que todos los esclavos no se han actualizado. PostgreSQL hace el registro disponible para los esclavos. Maestro: Es el servidor fuente de la data replicada y donde todas las actualizaciones suceden. Para la replicaci´ on. Solo se puede tener un solo maestro al utilizar las funcionalidades de replicaci´ on de PostgreSQL.1. Conceptos de replicaci´ on Para entender la replicaci´ on se deben comprender los conceptos utilizados. Es frecuentemente referido como el registro de transacciones en otras Bds. lo m´ as pr´ actico es agregar m´ as copias de la data y dividir la carga de trabajo entre todas.

lo cu´ al permite a un esclavo actuar como un maestro pero nada m´ as que para consultas de solo lectura. CREATE ROLE pgrepuser REPLICATION LOGIN PASSWORD ’woohoo’.168. se coloca una regla para permitir que los esclavos sean agentes de replicaci´ on. Replicaci´ on en cascada: Introducido en la versi´ on 9. En *nix el par´ ametro tendr´ a un aspecto como el siguiente: archive command = ’cp %p . host replication pgrepuser 192.\\archive\\ %f ’ 5. 2. El par´ ametro listen addresses de postgresql. Como ejemplo.conf debe permitir conexiones del esclavo.. Con streaming se puede escoger cualquier directorio pero debe asegurarse de que el usuario postgres pueda escribir en este. Alterar las siguientes configuraciones es postgresql.168.Streaming: El modelo de replicaci´ on por streaming fue introducido en la versi´ on 9.2.conf. En pg hba.2. los esclavos pueden recibir logs de otros esclavos. la siguiente regla va a permitir a una cuenta de usuario llamada pgrepuser en la red privada con una IP en un rango entre 192.0.0. wal level = hot standby archive mode = on max wal senders = 10 4.254 que utiliza una contrase˜ na en md5.0..1 y 192.168. Configurar una r´ eplica Para el ejemplo de replicaci´ on se utilizar´ a la replicaci´ on por Streaming de manera tal que el maestro y el esclavo se conecten mediante el protocolo de conexi´ on de PostgreSQL./archive/ %f ’ Y en Windows: archive command = ’copy %p .1. Configurar el maestro Los pasos b´ asicos para configurar el maestro son: 1. No requiere acceso directo a los archivos entre maestro y esclavo y se basa en el protocolo de de conexi´ on de PostgreSQL para transmitir los WALs. 3.0. 6.conf.0/24 md5 72 . Usar el par´ ametro archive command para indicar donde el WAL va a ser salvado. Crear una cuenta de usuario para la r´ eplica.

conf.. para ser un esclavo necesita reproducir las transacciones en el WAL (journal de la BD) del maestro. 4. standby mode = ’on’ primary conninfo = ’host=192. Esto no es un requerimiento estricto pero es recomendable.conf ) todos los directorios al directorio de datos del esclavo EXCEPTO los directorios pg xlog y pg log.O. Reescribir los archivos del directorio de datos con los archivos copiados del maestro..O. Establecer el siguiente par´ ametro en postgresql. Desactivar el servicio Postgresql y copiar del directorio de datos (se puede ver la ruta del directorio de la instalaci´ on espec´ ıfica en el par´ ametro data directory de postgresql.0.now’ El nombre del Host. Crear una nueva instancia de PostgreSQL con la misma versi´ on que el maestro y adem´ as el mismo S.pero debe asegurarse de que el usuario postgres pueda escribir en este: En un *nix: restore command = ’cp %p . 2. 1. 6. 7.conf de la Bd. hot standby = on 5.6. Para lo cu´ al se necesitan las siguientes instrucciones en el postgresql.conf la siguiente l´ ınea dependiendo del S. 73 . no es necesario que utilice el mismo del maestro. Crear un nuevo archivo en el folder de datos llamado recovery.1 port=5432 user=pgrepuser password=woohoo’ trigger file = ’failover. el esclavo debe tener la misma configuraci´ on del maestro. 3./archive/ %f ’ En Windows: restore command = ’copy %p .conf que contenga las siguientes l´ ıneas. Configurar el esclavo Para minimizar problemas. Desactivar PostgreSQL.168. Adem´ as de la configuraci´ on. por lo cu´ al necesita ponerlos en cache. Se puede utilizar el puerto por defecto o no. Agregar al archivo recovery. el IP y el puerto deben ser los del maestro. especialmente si se va a utilizar como reemplazo en caso de una ca´ ıda.\\archive\\ %f Estos comando solo son necesarios si el esclavo no puede reproducir el WAL del maestro con suficiente velocidad.

done y va a convertirse en un servidor independiente a partir de ese momento. se crea un archivo en blanco llamado failover. Cuando se desee liberar el esclavo. Luego de crear este archivo PostgreSQL va a renombrar el archivo recover. Iniciar el maestro. si da un error sobre la falta de maestro. 74 .Iniciar el proceso de replicaci´ on 1. Iniciar el esclavo primero.now en el directorio de datos del esclavo. ignorarlo.conf a recover. 2.

La diferencia entre ambos es que al partirlo por orderid si se eliminan los antiguos pedidos de la base de datos. los criterios que se consideran como buenas pr´ acticas son hacerlo cuando la tabla sea m´ as grande que la memoria f´ ısica o cuando alcance unos 100 millones de registros. Para llevar a cabo esta tarea. Por ejemplo. 7. Si la tabla es m´ as grande que la memoria del sistema el tiempo de consultas puede hacerse cada vez mayor. dividi´ endolas en tablas m´ as peque˜ nas y manejables. es com´ un que alguna tabla se convierta en inmanejable por su tama˜ no. dejar´ ıa una gran cantidad de registros para ser limpiados lo que har´ ıa m´ as lenta la 75 .2) | not null Si despu´ es de a˜ nos de trabajo la tienda ha recibido tantas o ´rdenes que las consultas a la tabla se hacen muy lentas. hay dos potenciales maneras de partir la data en partes m´ as peque˜ nas.2) | not null | numeric(12. no se necesita cambiar la aplicaci´ on debido a que Postgresql se hace cargo de gestionar las tablas. orderid | integer | not null valor por omision nextval(’orders_orderid_seq’::regclass) orderdate customerid netamount tax | date | integer | not null | | numeric(12. Otra forma es partirlo por fechas (orderdata ).1. Particionado Para saber cuando particionar una tabla. Una forma de lidiar con grandes tablas es particionarlas.Cap´ ıtulo 7 Particionado de tablas Al crecer una base de datos. considerando la tabla orders de la base de datos dellstore2 : \d orders. La primera ser´ ıa partir la tabla de acuerdo a su id (orderid ).2) | not null totalamount | numeric(12.

simplemente se borran las particiones que la contienen y el rendimiento de la base de datos no sufre. Esto permite a una tabla tener hijos que hereden sus columnas. 7.max(orderdate) FROM orders. Otro criterio importante al partir una tabla es que para beneficiarse de partir una tabla en pedazos.2. si se utilizan fecha para partir la data.2.1.. 2004-01-01 | 2004-12-31 SELECT relname.. Se deben tomar en cuentas los campos utilizados en la clausula WHERE como elementos para tomar la decisi´ on de que campo utilizar para dividir la tabla. 76 . SELECT min(orderdate). . En cambio. En este ejemplo se partir´ a la tabla orders en una partici´ on por mes. al querer eliminar data antigua. Crear las particiones Particionar en PostgreSQL se basa en las capacides de herencia de la tabla. las consultas deben realizarse sobre un subconjunto u ´til de la data.relpages FROM pg_class WHERE relname LIKE ’orders%’ ORDER BY relname. M´ etodos de Particionado Configuraci´ on de Particionado Un u ´til paso inicial antes de efectuar la partici´ on es obtener el rango de datos que contiene la tabla en relaci´ on al campo por el que se desea particionar y su tama˜ no.base de datos. orders | 94 1 29 orders_orderid_seq | orders_pkey | 7.3. 7. CREATE TABLE orders_2004_01 ( CHECK ( orderdate >= DATE ’2004-01-01’ and orderdate < DATE ’2004-02-01’) ) INHERITS (orders).

........ para agregar ´ ındices. ALTER TABLE ONLY orders_2004_12 ADD CONSTRAINT orders_2004_12_pkey PRIMARY KEY (orderid).... .. CREATE INDEX ix_orders_2004_12_custid ON orders_2004_12 USING btree (customerid). . CREATE TABLE orders_2004_12 ( CHECK ( orderdate >= DATE ’2004-12-01’ and orderdate < DATE ’2005-01-01’) ) INHERITS (orders). Adem´ as un ´ ındice manual en customerid es necesario: CREATE INDEX ix_orders_2004_01_custid ON orders_2004_01 USING btree (customerid).. 77 . . Cada orden contiene una restricci´ on a la llave for´ anea para asegurar que el cliente referenciado sea v´ alido. . . SQLs que van a crear un ´ ındice en orderid. restricciones y ajustar permisos se debe de hacer de forma manual: ALTER TABLE ONLY orders_2004_01 ADD CONSTRAINT orders_2004_01_pkey PRIMARY KEY (orderid). Pero solo se hereda la estructura de columnas de la tabla. Debe ser aplicada a cada partici´ on: ALTER TABLE ONLY orders_2004_01 ADD CONSTRAINT fk_2004_01_customerid FOREIGN KEY (customerid) REFERENCES customers(customerid) ON DELETE SET NULL.

1.3.*).ALTER TABLE ONLY orders_2004_12 ADD CONSTRAINT fk_2004_12_customerid FOREIGN KEY (customerid) REFERENCES customers(customerid) ON DELETE SET NULL. . Redirigir los INSERT a las particiones Luego de tener la estructura lista. END.orderdate >= DATE ’2004-12-01’ AND NEW.orderdate >= DATE ’2004-11-01’ AND NEW.*). Para hacerla m´ as corta solo se utilizar´ a la correspondiente a Enero.orderdate < DATE ’2005-01-01’ ) THEN INSERT INTO orders_2004_12 VALUES (NEW.. el siguiente paso es hacer que los registros insertados en la tabla padre vayan a la partici´ on apropiada.pero es una pr´ actica recomendada 78 . END IF. ELSIF ( NEW. 7. $$ LANGUAGE plpgsql.orderdate < DATE ’2004-02-01’ ) THEN INSERT INTO orders_2004_01 VALUES (NEW. ELSE RAISE EXCEPTION ’Error in orders_insert_trigger(): date out of range’.orderdate < DATE ’2004-12-01’ ) THEN INSERT INTO orders_2004_11 VALUES (NEW. ELSIF ( NEW..*). CREATE OR REPLACE FUNCTION orders_insert_trigger() RETURNS TRIGGER AS $$ BEGIN IF (NEW. RETURN NULL. La forma recomendada de hacerlo es con un trigger.orderdate >= DATE ’2004-01-01’ AND NEW.

orderdate < DATE ’2005-03-01’ ) THEN INSERT INTO orders_2004_02 VALUES (NEW.orderdate >= DATE ’2004-02-01’ AND NEW.orderdate >= DATE ’2004-01-01’ AND NEW.*).03. tax. RETURN NULL. 359.65).*). pero el trigger utilizar´ a la nueva funci´ on de manera autom´ atica una vez creada. lo m´ as probable es que se inserte data al final del rango: CREATE OR REPLACE FUNCTION orders_insert_trigger() RETURNS TRIGGER AS $$ BEGIN IF (NEW. $$ LANGUAGE plpgsql. customerid. 29. Una vez que la funci´ on ha sido creada. necesita ser llamada cada vez que un registro se inserte: CREATE TRIGGER insert_orders_trigger BEFORE INSERT ON orders FOR EACH ROW EXECUTE PROCEDURE orders_insert_trigger().empezar la funci´ on en el fin del rango (Diciembre). 388. netamount. La funci´ on puede necesitar actualizarse a medida que se agregan nuevas particiones. ELSIF ( NEW. END IF. END. 79 .62.orderdate < DATE ’2004-02-01’ ) THEN INSERT INTO orders_2004_01 VALUES (NEW. totalamount) VALUES (’2004-01-31’. 6765. Y comprobamos que se haya insertado en la tabla orders 2004 01. Para probar si funciona insertamos un registro en el rango de fechas deseado: INSERT INTO orders (orderdate. debido a que en escenarios de negocios. ELSE RAISE EXCEPTION ’Error in orders_insert_trigger(): date out of range’.

7. END IF.3. RETURN NULL. Trigger para los Updates Cuando en la tabla maestra se actualizan registros.3. INSERT INTO orders values(NEW. Y se crea la regla: CREATE RULE orders_2004_01_insert AS ON INSERT TO orders WHERE ( orderdate >= DATE ’2004-01-01’ AND orderdate < DATE ’2004-02-01’ ) DO INSTEAD INSERT INTO orders_2004_01 VALUES (NEW. se elimina el trigger: DROP TRIGGER insert_orders_trigger ON orders.*). el rendimiento puede disminuir a medida que aumentan las particiones. Utilizar reglas de partici´ on Existe otra manera de implementar la redirecci´ on a la partici´ on llevada a cabo mediante el trigger.*).orderdate != OLD. Con este fin se instala el siguiente trigger: CREATE OR REPLACE FUNCTION orders_2004_01_update_trigger() RETURNS TRIGGER AS $$ BEGIN IF ( NEW. La ventajas de las reglas es que son m´ as eficientes insertando grandes cantidades de registros al mismo tiempo. Y debido a que las reglas son proporcionales al n´ umero de particiones. estos deben guardarse no en la tabla maestra sino en la partici´ on correspondiente. Mediante una funcionalidad llamada rules (reglas) de PostgreSQL se puede substituir un comando por otro que se desee. Y comprobamos si funciona insertando un registro. 80 .2.3. pero los triggers son superiores al insertar registros de uno en uno. En pocas palabras es mejor utilizar triggers para particionar tablas.orderid=orderid.orderdate ) THEN DELETE FROM orders_2004_01 WHERE OLD. Para implementar la regla. 7.

orderid=orderid.END. Otro m´ etodo es si se instala el trigger para los updates en la tabla padre. Otra opci´ on es hacer un backup de la tabla. Migraci´ on de la data Luego de crear las particiones. INSERT INTO orders values(NEW. la aproximaci´ on m´ as prudente es incluir todo en un BEGIN/COMMIT. lo que requeriria una ventana de mantenimiento. de tal manera que si algo sale mal. END. Esta es la forma habitual como se llevar´ ıa a cabo la partici´ on de la data para no interrumpir el funcionamiento de la aplicaci´ on.*). Al llevar a cabo una migraci´ on. al actualizarse toda la tabla se migrar´ ıa la data. CREATE TRIGGER update_orders_2004_01 BEFORE UPDATE ON orders_2004_01 FOR EACH ROW EXECUTE PROCEDURE orders_2004_01_update_trigger(). los ´ ındices y las funciones ahora se tiene toda la data en la tabla orders y particiones vacias. crear la estructura de las particiones y recargar la data. nada se lleva a cabo. $$ LANGUAGE plpgsql.3. 81 . CREATE TRIGGER update_orders BEFORE UPDATE ON orders FOR EACH ROW EXECUTE PROCEDURE orders_update_trigger().4. 7. RETURN NULL. $$ LANGUAGE plpgsql. Este es el c´ odigo necesario: CREATE OR REPLACE FUNCTION orders_update_trigger() RETURNS TRIGGER AS $$ BEGIN DELETE FROM orders WHERE OLD.

77. DROP FUNCTION orders_update_trigger()..1292.62..00 82 .00 rows=12001 width=36) (actual time=4..00. CLUSTER orders USING ix_order_custid.00. Luego se hace un count de las particiones: SELECT count(*) FROM orders_2004_01.453.00 rows=1 width=36) (actual time=4.445.. Luego se eliminan el trigger y la funci´ on que realizar´ on la migraci´ on para evitar futuras confuciones: DROP TRIGGER update_orders ON orders.. QUERY PLAN ---------Result (cost=0..153 rows=0 loops=1) -> Seq Scan on orders_2004_01 orders (cost=0.153.258 rows=12000 loops=1) -> Seq Scan on orders (cost=0. Se ejecuta ANALYZE para actualizar las estad´ ısticas de la base de datos y se verifica que constraint exclusion este activa. Para limpiar la tabla padrea se utilizar´ a CLUSTER para reconstruirla.00. Constraint exclusion permite al planificador evitar incluir particiones en una consulta cuando estas no van a proveeder de registros relevantes.1292.102.062 rows=12000 loops=1) -> Append (cost=0. Se observa que las particiones tienen la data correspondiente pero que la tabla padre a´ un tiene toda la data. SHOW constraint_exclusion.00.Para ejecutar la funci´ on se llama al trigger: UPDATE orders SET orderid=orderid WHERE ORDERDATE < ’2004-03-01’.4. Se puede volver a ejecutar una consulta con toda la tabla y verificar las estad´ ısticas: EXPLAIN ANALYZE SELECT * FROM orders..00 rows=12001 width=36) (actual time=4. ANALYZE.400.

400.50 rows=35 width=36) (actual time=0.045 rows=1000 loops=1) Para probar el valor de las particiones.00.77.. Al eliminar data.00 rows=1 width=36) (actual time=1. Si se desea eliminar un rango de fechas del servidor de producci´ on. esta no queda ocupando espacio.2.432.189. 7.00..141 rows=35 loops=1) -> Append (cost=0.00. se hace un backup y se eliminan las particiones con la data antigua.. solo recorre aquella correspondiente a la fecha solicitada.971 rows=1000 loops=1) -> Seq Scan on orders_2004_02 orders (cost=0.276 ms En lugar de recorrer todas las particiones.50 rows=36 width=36) (actual time=1.. Es m´ as sencillo el mantenimiento de data hist´ orica..2. se puede probar con una consulta que solo consulte un d´ ıa puntual: EXPLAIN ANALYZE SELECT * FROM orders WHERE orderdate=’2004-01-16’. Crear nuevas particiones Cuando sea necesario crear nuevas particiones se debe modificar el trigger y la funci´ on relacionada de tal manera que continue funcionando sin novedad el particionado.6.1.rows=1000 width=36) (actual time=0. QUERY PLAN ---------Result (cost=0..0.189 rows=0 loops=1) Filter: (orderdate = ’2004-01-16’::date) -> Seq Scan on orders_2004_01 orders (cost=0..3.471..71.017 rows=35 loops=1) -> Seq Scan on orders (cost=0.00 rows=1000 width=36) (actual time=0.5. 7.3..718 rows=35 loops=1) Filter: (orderdate = ’2004-01-16’::date) Total runtime: 2. es eliminada junto con la partici´ on borrada 83 .00.1.238.437.00..2.287. Ventajas de las particiones Existen diversas ventajas en usar particiones para una tabla: Las b´ usquedas son m´ as veloces.471..50 rows=36 width=36) (actual time=1.267.

No escribir robustos el trigger o la funci´ on. No asignar los permisos necesarios a las particiones.3.7.7. 84 . No utlizar el campo por el que se particiono al hacer consultas. No agregar todas los constrains e ´ ındices necesarios a cada partici´ on. Errores al particionar Existen algunos errores comunes al particionar una tabla: No tener constraint exclusion en ON.

Se ejecuta como un solo proceso. cuanto de la base de datos est´ a en memoria y la velocidad de los discos. El sobrecosto se acepta sin problemas si se est´ a llevando a cabo un complejo JOIN. pero no se recomienda utilizar un pool de conexiones hasta que el servidor este sobrecargado de trabajo. toda conexi´ on nueva solo degrada su eficiencia. En una instalaci´ on de *nix. el sobrecosto de abrir una conexi´ on a la base de datos y esperar a que se ejecute la consulta puede ser muy alto. Para m´ as informaci´ on al respecto se puede ver en: http://wiki. no abriendo un proceso por cada conexi´ on. Una vez que el servidor ya est´ a activo continuamente. Al ejecutar PostgreSQL como servicio. se le asignan 512KB para trabajar. PgBouncer Originado como parte de Skype. Realizar pooling de conexiones va a ayudar si se tienen cientos o m´ as conexiones y los procesadores est´ an siendo utilizados en un elevado porcentaje. pero si solo se efectua una lectura simple. por lo que si cada conexi´ on toma 3. una de sus limitaciones es el sobrecosto que se paga al ejecutar incluso la m´ as peque˜ na consulta.2.org/wiki/Running %26 Installing PostgreSQL On Native Windows. La cantidad de conexiones depende de los n´ ucleos en el sistema. El pool de conexiones La raz´ on principal para utilizar un pool de conexiones es que se deben tener suficientes conexiones para utilizar todos los recursos disponibles pero no m´ as que eso.1. y cualquier gestor de bases de datos. PgBouncer es el software para pooling con el mayor rendimiento disponible.5KB de espacio no se pueden tener m´ as de 125.Cap´ ıtulo 8 Pooling de conexiones Cuando se trabaja con PostgreSQL. el l´ ımite es menor. 8. el punto en que agregar nuevas conexiones se vuelve oneroso est´ a entre las 500 y 1000 activas.postgresql. 8. En general tener menos conexiones abiertas es mejor. Existen algunas reglas pr´ acticas para decidir si se tienen muchas conexiones. 85 . [5] En los sistemas Windows.

txt : 86 . Para agregar m´ as bases de datos solo se deben de agregar en la secci´ on [databases]. Y en userlist. se puede utilizar el comando SHOW para mostrar informaci´ on sobre el estado interno del pool de conexiones.0. sirviendo para proveer informaci´ on y de consola de control.0. uno donde se establecen los par´ ametros de configuraci´ on y conexi´ on y otro donde se definen los usuarios de la base de datos que podr´ an utilizar PgBouncer.0.Al monitorear las conexiones. Configurar PgBouncer Para conectarse a una base de datos a trav´ es de PgBouncer se necesitan dos archivos de configuraci´ on ubicados en /etc/pgbouncer. Al conectarse mediante psql al puerto donde se ejecuta PgBouncer. PgBouncer se puede conectar con m´ ultiples bases de datos. Se mueve cada base de datos a su propio host y se les une mediante PgBouncer como intermediario y la aplicaci´ on no necesitar´ a ser cambiada.1 port=5432 dbname=Bd_prueba [pgbouncer] listen_port = 6543 listen_addr = 127.ini “user” es el usuario que va administrar pgbouncer. lo que permite una forma de particionar para escalar.0.1.1 port=5432 dbname=template1 Bd_prueba = host=127. Se agregan adem´ as los usuarios de la base de datos.2.ini se escribir´ a la siguiente configuraci´ on: [databases] template1 = host=127.txt logfile = pgbouncer. 8.0.txt : En pgbouncer. Instalaci´ on de PgBouncer Para instalar PgBouncer en Ubuntu. ejecutar: $ sudo apt-get install pgbouncer 8.0. ya sea en el mismo host o en diferentes.1 auth_type = md5 auth_file = userlist.log pidfile = pgbouncer. El primero es pgbouncer.ini y el segundo userlist.2. despliega la informaci´ on mediante una interfaz de base de datos a la que se le pueden aplicar consultas.2.pid admin_users = user En pgbouncer.

87 . mediante SHOW HELP se pueden mostrar los comandos existentes: SHOW HELP."user" "password" Para iniciar PgBouncer ejecutar el comando: pgbouncer -d pgbouncer.ini Para conectarse a una base de datos a trav´ ez de PgBouncer escribir: psql -p 6543 -h localhost -U user-base-datos template1 Para conectarse a PgBouncer escribir: psql -p 6543 -h localhost -U user pgbouncer Al conectarse a PgBouncer. NOTICE: DETALLE: Console usage SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION SHOW STATS|FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM SHOW DNS_HOSTS|DNS_ZONES SET key = arg RELOAD PAUSE [<db>] RESUME [<db>] KILL <db> SUSPEND SHUTDOWN SHOW Si se hacen cambios en pgbouncer.ini y se desea recargar el archivo de configuraci´ on: RELOAD.

8. En el ejemplo el servidor estar´ a presente en el mismo host que PgPool. Adem´ as. Estos servidores pueden estar en el mismo host donde se encuentra PgPool o en otro host.conf agregando el usuario y su password en md5.conf : admin:e10adc3949ba59abbe56e057f20f883e 8. Configuraci´ on de PgPool II Para configurar el origen de conexiones a PgPool.1.3.3. con cada conexi´ on esperando para que su conexi´ on de red sea aceptada. Adem´ as soporta algunas configuraciones para consultas en paralelo.conf y se da el valor ’*’ al par´ ametro listen adresses. puede ser significativa. El sobrecosto de memoria de esa aproximaci´ on. Instalar PgPool II Para instalar PgPool II en Ubuntu ejecutar: sudo apt-get install pgpool2 8.3.conf y se escriben los siguientes par´ ametros: 88 . PgPool II Es el m´ as antiguo de los paquetes utilizados para pooling de conexiones con PostgreSQL que a´ un sigue en desarrollo.3. se abre el archivo pgpool. donde las consultas son partidas en pedazos y repartidas entre los nodos donde cada una tiene una copia de la informaci´ on solicitada. listen adresses = ’*’ Para configurar los usuarios que pueden acceder a la interfaz de administraci´ on se configura el archivo pcp. El “pool” en pgpool es sobre todo para gestionar m´ ultiples servidores.2. Para generar un password en md5 utilizamos el comando pg md5 y el password que deseamos cifrar: pg md5 123456 El resultado lo incluimos en pcp. Para configurar se accede al archivo pgpool. Preparar los nodos de bases de datos Se deben establecer los servidores PostgreSQL para PgPool. Su funci´ on principal no es solo el pooling de conexiones. las adicionales son encoladas en el sistema operativo. Cada conexi´ on es establecida en su propio proceso como en el servidor.3. PgPool tiene algunas limitaciones en el pooling de conexiones. 8. adem´ as provee balanceo de carga y capacidades de replicaci´ on. y pgpool sirve como proxy entre el cliente y cierto n´ umero de bases de datos. en pgpool una vez se sobrepasa la cantidad de conexiones que maneja el software. con cada proceso utilizando una porci´ on de memoria.

Para terminar el proceso se ejecuta: pgpool stop Si hay clientes conectados y se desea desactivar el servicio a la fuerza: pgpool -m fast stop 8.3. 8. Activar PgPool II Para activar pgpool-II.3. Conectarse a PgPool II El puerto por defecto figura en el archivo pgpool. Para saber si PgPool est´ a activo y aceptando conexiones ejecutar: ps -ef | grep pgpool root root root root root root root root root root 6586 6587 6588 6589 6590 6591 6592 6593 6594 6595 3013 6586 6587 6587 6587 6587 6587 6587 6587 6587 0 0 0 0 0 0 0 0 0 0 20:35 20:35 20:35 20:35 20:35 20:35 20:35 20:35 20:35 20:35 pts/1 pts/1 pts/1 pts/1 pts/1 pts/1 pts/1 pts/1 pts/1 pts/1 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 sudo pgpool -n -d pgpool -n -d pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection pgpool: wait for connection request request request request request request request request Si todo est´ a conforme se ejecuta psql para conectarse a PgPool: 89 . se utiliza el comando: pgpool -n -d > /tmp/pgpool.4. se agrega m´ as par´ ametros cambiando el n´ umero para reflejar el n´ umero del servidor. El par´ ametro backend weight0 indica que se est´ Si se desean m´ as servidores.5.conf. en el caso del presente ejemplo es 5433.log y se ejecuta en segundo plano.backend hostname0 = ’localhost’ backend port0 = 5432 backend weight0 = 1 a ejecutando un solo servidor sin balanceo de carga. Antes de ejecutarlo se debe cerrar cualquier programa que este editando un archivo de configuraci´ on de PgPool.log 2>&1 & Esta instrucci´ on genera un log en /tmp/pgpool.

psql -p 5433 -h localhost -U pedro -d Bd prueba Una vez en la base de datos, adem´ as de los comandos SQL habituales, se pueden ver datos propios de PgPool como: pool pool pool pool pool status, to get the configuration nodes, to get the nodes information processes, to get information on pgPool-II processes pools, to get information on pgPool-II pools version, to get the pgPool-II release version

90

Cap´ ıtulo 9 Lenguajes Procedurales
Como en otras bases de datos, se pueden juntar expresiones SQL y volverlas una unidad. tiene diferentes nombres seg´ un el motor utilizado: procedimientos almacenados, m´ odulos, macros, etc. En PostgreSQL se llaman funciones y adem´ as de permitir juntar varias expresiones SQL, permiten tambi´ en utilizar l´ ogica para dirigir el flujo del programa. En PostgreSQL existen diversos lenguajes que se pueden utilizar para escribir funciones y que con frecuencia vienen ya empaquetados: SQL, C, PL/pgSQL, PL/Perl, PL/Python. Se pueden instalar adem´ as otrs lenguajes como R, Java, sh e incluso algunos experimentales como Scheme. Para ver una lista de los lenguajes disponibles acceder a: http://www.postgresql.org/docs/current/interactive/external-pl.html

9.1.

Estructura de una funci´ on

Sin importar que lenguaje se escoge para escribir una funci´ on, todas comparten una misma estructura:

CREATE OR REPLACE FUNCTION func_name( arg1 arg1_datatype) RETURNS some_type | setof sometype | TABLE (..) AS $$ BODY of function $$ LANGUAGE language_of_function Para listar la lista de lenguajes en la base de datos se ejecuta:

SELECT lanname FROM pg_language;

91

La definici´ on de una funci´ on puede incluir atributos adicionales para optimizar la ejecuci´ on y mejorar la seguridad:

LANGUAGE: Debe ser uno instalado en la base de datos. VOLATILITY: Por defecto es VOLATILE si no es especificado. Puede ser establecido como STABLE, VOLATILE o IMMUTABLE. Estas configuraciones le dan una idea al planificador sobre si los resultados de la funci´ on pueden ser colocados en la cache. STABLE significa que la funci´ on va a retornar el mismo valor para la misma entrada y la misma consulta. VOLATILE significa que la funci´ on puede retornar un valor diferente con cada llamada del sistema. INMUTABLE significa que dada una entrada, la salida siempre va a ser la misma. STRICT: Una funci´ on es asumida como no estricta a menos que tenga el atributo STRICT. Una funci´ on STRICT siempre retorna NULL si alguna entrada es NULL. COST: Es una medida relativa de la intensidad de computo. Las funciones SQL y PL/PgSQL tienen un valor por defecto de 100 y las de C de 1. Amayor el valor, se asume que la funci´ on es m´ as costosa. ROWS: Es un estimado de cuantos registros va a devolver la funci´ on. El formato es ROWS 100. SECURITY DEFINER: Cl´ ausula opcional que implica que la funci´ on se ejecuta en el contexto del due˜ no dela funci´ on. Si no se coloca, la funci´ on se ejecuta en el contexto del usuario actual.

9.2.

Funciones SQL

Escribir funciones en SQL es sencillo. Se agrega la estructura y se tiene la funci´ on. Debido a que no es un lenguaje propiamente dicho, en SQL no hay estructuras de control. No puede haber m´ as de una sentencia SQL (se pueden utilizar sub consultas). Ejemplo:

CREATE OR REPLACE FUNCTION ins_logs(param_user_name varchar, param_description text) RETURNS integer AS $$ INSERT INTO logs(user_name, description) VALUES($1, $2) RETURNING log_id; $$ LANGUAGE ’sql’ VOLATILE; Para llamar a la funci´ on se ejecuta:

SELECT ins_logs(’lhsu’, ’this is a test’) As new_id; Para retornar conjuntos de registros existes tres alternativas: RETURNS TABLE, usar par´ ametros OUT, o retornar un tipo de datos compuesto. [3]

92

user_name.3. description. 9. Se diferencia de SQL en que se pueden declarar variables utilizando DECLARE.Ejemplo de RETURNS TABLE: CREATE FUNCTION sel_logs_rt(param_user_name varchar) RETURNS TABLE (log_id int. description text. OUT log_ts timestamptz) RETURNS SETOF record AS $$ SELECT * FROM logs WHERE user_name = $1. $$ LANGUAGE ’sql’ STABLE. OUT user_name varchar. OUT log_id int . $$ LANGUAGE ’sql’ STABLE. la opci´ on m´ as com´ un es PL/pgSQL. Usando un tipo de dato compuesto: CREATE FUNCTION sel_logs_so(param_user_name varchar) RETURNS SETOF logs AS $$ SELECT * FROM logs WHERE user_name = $1. Utilizando par´ ametros OUT: CREATE FUNCTION sel_logs_out(param_user_name varchar. log_ts FROM logs WHERE user_name = $1. Todas las funciones pueden ser llamadas usando: SELECT * FROM sel_logs_rt(’lhsu’). existen instrucciones 93 . log_ts timestamptz) AS $$ SELECT log_id. OUT description text. user_name varchar(50). $$ LANGUAGE ’sql’ STABLE. Funciones PL/pgSQL Cuando las necesidades escapan de los l´ ımites del SQL puro.

log_ts timestamptz) AS $$ BEGIN RETURN QUERY SELECT log_id. Desde Pl/Pyton se pueden retornar arreglos e incluso tipos de datos compuestos. Los lenguajes “untrusted” se reconocen debido a que llevan una “u” al final de su nombre.4. En PostgreSQL se pueden escribir funciones utilizando Python.1. 9. END.de control de flujo y el cuerpo de la funci´ on debe de estar entre BEGIN y END. Est´ an soportadas tanto Python 2 como Python 3. Para utilizar Python. Ejemplo: CREATE FUNCTION sel_logs_rt(param_user_name varchar) RETURNS TABLE (log_id int. $$ LANGUAGE ’plpgsql’ STABLE. log_ts FROM logs WHERE user_name = param_user_name. description text.4. user_name. 9. Se puede utilizar python para escribir Triggers y crear funciones de agregaci´ on. Funciones en PL/Python Python es un lenguaje popular con gran cantidad de librer´ ıas. se debe instalar el paquete de software que contiene la extensi´ on. en Ubuntu: sudo apt-get install postgresql-plpython-9.2 Luego se ingresa en la base de datos y se instala la extensi´ on: CREATE EXTENSION plpython2u. Pl/Python es un lenguaje “untrusted” debido a que puede interactuar con el sistema operativo y por lo tanto una funci´ on solo puede ser creada por un superusuario. Un usuario puede escribir funciones en PL/Python si es que al crearse se le dio el atributo SECURITY DEFINER. user_name varchar(50). Funci´ on python b´ asica PostgreSQL convierte autom´ aticamente los tipos de PostgreSQL a tipos de dato Python y viceversa. description. 94 .

find("<!-.org/search/?u=%2Fdocs%2Fcurrent%2F&q=’+param_search) raw_html = response. result). CREATE OR REPLACE FUNCTION postgresql_help_search(param_search text) RETURNS text AS $$ import urllib. ’’. 2.1] result = re.read() result = raw_html[raw_html.docbot goes here -->"):raw_html. Lo que hace la funci´ on es: 1. Concatenar el t´ ermino de b´ usqueda con la direcci´ on web. Importar las librer´ ıas a utilizar.sub(’<[^<]+?>’. En el siguiente ejemplo se muestra como hacer una funci´ on que haga una b´ usqueda de texto en la web de documentaci´ on de PostgreSQL. Otro ejemplo permitir´ a interactuar con el sistema operativo: 95 . Leer la respuesta y guardarla en una variable llamada raw html. 3. (’tsvector’)) As X(search_term). Elimina los tags HTML y los espacios en blanco al inicio y final y guarda en result.urlopen \ (’http://www. 125) As result FROM (VALUES (’regexp_match’). 4. left(postgresql_help_search(search_term).\ pgContentWrap -->") . Retorna el resultado final result. Guardar la parte de raw html que empieza con <!– docbot goes here –> y termina antes de <!– pgContentWrap –>. re response = urllib. 6. (’pg_trgm’).Python permite llevar a cabo tareas que no son factible en SQL o PL/pgSQL.find("<!-.strip() return result $$ LANGUAGE plpython2u SECURITY DEFINER STABLE.postgresql. 5. Llamar a una funci´ on Python no es diferente que llamar a funciones en otros lenguajes: SELECT search_term.

Ejemplo de acceso a data desde plpython mediante la librer´ ıa plpy.fetch(batch_size) if not rows: break for row in rows: if row[’num’] % 2: odd += 1 return odd 96 .SPIError: return "something went wrong" else: return "Joe added" $$ LANGUAGE plpythonu. CREATE FUNCTION count_odd_fetch(batch_size integer) RETURNS integer AS $$ odd = 0 cursor = plpy.cursor("SELECT num FROM largetable") while True: rows = cursor.CREATE OR REPLACE FUNCTION list_incoming_files() RETURNS SETOF text AS $$ import os return os.listdir(’/tmp’) $$ LANGUAGE ’plpython2u’ VOLATILE SECURITY DEFINER. CREATE FUNCTION try_adding_joe() RETURNS text AS $$ try: plpy.execute("INSERT INTO users(username) VALUES (’joe’)") except plpy. Para ejecutarlo: SELECT * FROM list_incoming_files().

este es un mensaje de prueba’ message = MIMEText(msg) message[’From’] = ’Example <’ + fromaddr message[’To’] = toaddrs message[’MIME-Version’] = ’1. 9. utilitarios. aplicaciones de escritorio. Se caracteriza por tener una baja curva de aprendizaje.4.3. Expl´ ıcito es mejor que impl´ ıcito. 9. din´ amico y multiparadigma (POO.$$ LANGUAGE plpythonu. etc.MIMEText import MIMEText fromaddr = ’pmunoz@gmail.0’ message[’Content-type’] = ’text/HTML’ message[’Subject’] = ’Asunto’ + ’>’ # Credentials (if needed) usuario = ’usuario’ password = ’password’ 97 .2. ser multiuso y permitir una programaci´ on ordenada y elegante.com’ msg = ’Hola. sistemas de informaci´ on. Aspectos b´ asicos de Python Python es un lenguaje de programaci´ on interpretado.4. Python se ha utilizado para todo tipo de desarrollos incluyendo Web. Su visi´ on est´ a expresa en el Zen de Python: Bello es mejor que feo. Ejemplo de Python import smtplib from email. Simple es mejor que complejo. estructurado).com’ toaddrs = ’pedro@simuder.

N´ umeros: 5 (entero). Cadenas: ”Gobierno regional”. message.# The actual mail send server = smtplib.4 >>> a 6.com:587’) server. 4.4.4 >>> a = "Chiclayo" >>> a 98 .SMTP(’smtp. Booleanos: True y False Los comentarios se escriben utilizando el s´ ımbolo #: \# Este es un comentario a = "Esta es una linea de programa" Las variables se asignan de forma din´ amica y dependen del tipo de dato que se les asigna.login(usuario. por ejemplo.4. una variable puede ser entera.quit() Para empezar a experimentar con Python se puede utilizar el int´ erprete interactivo desde la consola: python 9. 4 + 6j (complejo). Tipos b´ asicos Los tipos b´ asicos son en esencia tres: n´ umeros.sendmail(fromaddr.7 (flotante). toaddrs. cadenas y valores booleanos.starttls() server.password) server.gmail. luego asignarsele un valor de coma flotante y por u ´ltimo una cadena y es v´ alido: >>> a = 5 >>> a 5 >>> a = 6.as_string()) server.

’Chiclayo’ >>> Cadenas Existen tres tipo de cadenas: Las cadenas normales.5.0 r=7 Si en una operaci´ on utilizamos un n´ umero flotante y un entero el resultado ser´ a flotante.75 r = 3. las cadenas unicode y las cadenas “crudas” (raw en ingl´ es). >>> a = “˜ n” >>> print “a” n ˜ >>> b =“˜ n” >>> print b n ˜ >>> a u’\xf1’ >>> b ’\xc3\xb1’ >>> c = r“\n” >>> c ’\\n’ >>> print c \n >>> 9.5 / 2 # r es 1.4.7 # r es -3 r = -7 # r es -7 r = 2 * 6 # r es 12 r = 2 ** 6 # r es 64 r = 3.5 // 2 # r es 1. Operadores Operador + * ** / // % Descripci´ on Suma Resta Negaci´ on Multiplicaci´ on Exponente Divisi´ on Divisi´ on entera M´ odulo Ejemplo r = 3 + 2 # r es 5 r = 4 . 99 .

15] >>> l. tuplas y diccionarios. etc.6. Son colecciones de datoa que pueden tener cualquier tipo de dato: n´ umeros. "Hotel") >>> tupla[0] 1 >>> tupla[0:2] 100 . ’mee’] Tuplas Las tuplas se parecen a las listas. True. [1. [1. cadenas. 2]. excepto por dos puntos: Se definen de forma diferente y son inmutables. 2]] >>> >>> l[0:2] [22.9. [1."Hola".5. 15] >>> l[:2] [22.4. 15. >>> tupla = (1. True. objetos. 15.append("mee") >>> l [22. Listas Las listas son el caballo de batalla de Python. "una lista". 2]] >>> l[2] ’una lista’ >>> l[3][0] 1 >>> l[1] = 15 >>> l [22. otras listas. Para crear una lista se agrupan los objetos en corchetes separados por comas: >>> l = [22. ’una lista’. ’una lista’. Colecciones Los tipos de colecciones de datos m´ as utilizados en Python son: listas.

Como clave se puede utilizar cualquier valor inmutable: n´ umeros. "Michel Corleone": "Al Pacino"} >>> d {’Michel Corleone’: ’Al Pacino’.7. >>> d = {"Don Corleone": "Marlon Brando".(1. las tuplas son m´ as ligeras en memoria. Control de flujo El control de flujo son los condicionales y bucles: x = 10 y = 50 if x > 10 and y > 60: print "x mayor que 10 e y mayor que 60" elif x > 5 and y < 100: print "x mayor que 5 e y menor que 100" else: print "ninguna de las anteriores" 101 . Diccionarios Son colecciones que relacionan una llave y un valor. El primer valor es la clave y el segundo el valor asociado a la clave. A un diccionario se accede solo por la llave. 5) >>> t = (1) >>> type(t) <type ’int’> >>> t = (1.4. booleanos. tuplas.) >>> type(t) <type ’tuple’> A cambio de no ser modificables. cadenas. ’Don Corleone’: ’Marlon Brando’} >>> d["Don Corleone"] ’Marlon Brando’ 9. ya que no tienen orden interno.

*otros): """Funcion con numero variable de parametros:W 102 .j) + " para alcanzar a " + str(x) l = [4. def primera_funcion(param1.8. x = 5 for j in range(x): print "a " + str(j) + " le faltan " + str(x . i = 0 while i < 20: print str(i) + " es menos de 20" i = i + 1 En Python. 6.8] for item in l: print item 9. Funciones Una funci´ on es un fragmento de c´ odigo con un nombre asociado que realiza una serie de tareas y devuelve un valor.. "Segundo". el bucle for .En Python no existe el switch. in se utiliza como una forma gen´ erica de iterar sobre una secuencia. False."la") def varios(param1.4) print "\n" print primera_funcion("Ho".. param2. param2): suma = param1 + param2 return suma print primera_funcion(5.4. "Chiclayo".

""" print param1 print param2 for val in otros: print val varios(1.5) 9. Su salida siempre es un tipo llamado trigger. END.orderid=orderid. Donde difieren es en el par´ ametro de entrada y en la salida.3. Funciones Trigger PostgreSQL ofrece Triggers a nivel de registro y de tablas y vistas. PostgreSQL ofrece funciones especializadas en gestionar los triggers que actuan como cualquier otra funci´ on y tienen la misma estructura b´ asica.*). Cada trigger debe tener asociada unafunci´ on trigger y para tener m´ ultiples triggers se deben crear m´ ultiples funciones sobre el mismo evento las cuales se ejecutaran en orden alfab´ etico. El m´ as utilizado es PL/pgSQL.2. Una funci´ on trigger nunca recibe un input aunque internamente tiene acceso a la data del trigger y puede modificarla. END IF.orderdate ) THEN DELETE FROM orders_2004_01 WHERE OLD. Se siguen dos pasos: en primer lugar escribir la funci´ on y luego el trigger correspondiente.3. Por ejemplo: CREATE OR REPLACE FUNCTION orders_2004_01_update_trigger() RETURNS TRIGGER AS $$ BEGIN IF ( NEW.orderdate != OLD.2. Se puede usar cualquier lenguaje menos SQL para escribir triggers. RETURN NULL.2) varios(1.4.9.4) varios(1.4. $$ 103 . INSERT INTO orders values(NEW.

Lo primero que se hace es definir la funci´ on trigger que elimina un valor antiguo e inserta el valor nuevo del registro. 104 .LANGUAGE plpgsql. El trigger se ejecutar´ a antes de que se actualize un registro de la tabla orders 2004 01. CREATE TRIGGER update_orders_2004_01 BEFORE UPDATE ON orders_2004_01 FOR EACH ROW EXECUTE PROCEDURE orders_2004_01_update_trigger().

Si se desea instalar la extensi´ on en un esquema particular. Se puede tener una base de datos con una extensi´ on y las dem´ as no tenerla. estas ya se encuentran precompiladas y solo falta instalarlas. Para ver las extensiones instaladas se ejecuta: SELECT * FROM pg available extensions. Si se desea que todas las bases de datos tengan un esquema. Para tener los detalles de una extensi´ on en particular se utiliza el siguiente comando: \dx+ plpgsql 10. los add-ons son instalados con facilidad mediante el nuevo modelo de extensiones. En el caso de las extensiones m´ as comunes. Las extensiones son instaladas por separado en cada base de datos. 105 .1. a partir de esa versi´ on. La forma moderna y sencilla de instalar una extensi´ on es: CREATE EXTENSION fuzzystrmatch. este se debe instalar en la base de datos template1 para que al crearse una nueva. t´ ermino que ha reemplazado a contrib.Cap´ ıtulo 10 Extensiones y contrib Las extensiones y los m´ odulos contribs son Add-ons que se pueden instalar en una base de datos para extender su funcionalidad m´ as all´ a de lo que ofrece PostgreSQL. Instalar Extensiones Para instalar una extensi´ on se deben de colocar sus scripts en share/extension y sus binarios en lib y bin. tenga a su vez la extensi´ on deseada. Antes de PostgreSQL 9.1 los add-ons se llamaban contribs. primero se crea el esquema y luego se instala la extensi´ on: CREATE EXTENSION fuzzystrmatch SCHEMA my extensions.

pgcrypto: Provee herramientas de cifrado incluyendo PGP.10. 106 . Algunas de las m´ as populares son: Postgis: Una extensi´ on que coloca a PostgreSQL entre las principales bases de datos geogr´ aficas. dblink: M´ odulo que permite hacer consultas a otras bases de datos. fuzzystrmatch: Es una extensi´ on ligera para trabajar de forma difusa con cadenas. Es el u ´nico mecanismo para trabajar entre bases de datos con PostgreSQL. Est´ a compuesto de m´ as de 800 funciones. tipos e ´ ındices espaciales. Extensiones Comunes Diversas extensiones vienen empaquetadas con PostgreSQL pero no son instaladas por defecto. guardar data pseudo normalizada. Util pg trgm: Una extensi´ on utilizada para manejar de forma difusa cadenas de texto. hstore: Es una extensi´ on que agrega almacenamiento por llave y valor (tipo diccionario) para ´ para servir de intermedio entre relacional y NoSQL.2.

. PostgreSQL: Up and Running. 2012. SQL FOR SMARTIES: ADVANCED SQL PROGRAMMING THIRD EDITION. Leo. 2013. O’Reilly. [2] Group. The PostgreSQL Global Development. Morgan Kaufmann.3 Documentation.0 High Performance. PostgreSQL 9. PostgreSQL 9. Gregory. Regina y Hsu. 107 .3 Documentation. Packt Publishing. 2005.2. Postgresql como funciona una base de datos por dentro. 2010. [5] Smith. JOE. [3] Obe.2. Ernesto.Fuentes de Informaci´ on [1] CELKO. PostgreSQL 9. Birmingham – UK. [4] Qui˜ nones.