Revisi�n de las caracter�sticas internas de PostgreSQL

NotaAutor
 

Este cap�tulo apareci� originalmente como parte de la tesis doctoral de Stefan Simkovic preparada en la Universidad de Tecnolog�a de Viena bajo la direcci�n de O.Univ.Prof.Dr. Georg Gottlob y Univ.Ass. Mag. Katrin Seyr.

Este cap�tulo da una visi�n general de la estructura interna del motor de Postgres. Tras la lectura de las siguientes secciones, usted tendr� una idea de como se procesa una consulta. No espere aqu� una descripci�n detallada (�creo que esa descripci�n detallada incluyendo todas las estructuras de datos y funciones utilizadas en Postgres exceder�a de 1000 p�ginas!). Este cap�tulo intenta ayudar en la comprensi�n del control general y del flujo de datos dentro del motor desde que se recibe una consulta hasta que se emiten los resultados.

El camino de una consulta

Damos aqu� una corta revisi�n a los pasos que debe seguir una consulta hasta obtener un resultado.

  1. Se ha establecido una conexi�n desde un programa de aplicaci�n al servidor Postgres. El programa de aplicaci�n transmite una consulta y recibe el resultado enviado por el servidor.

  2. La etapa del parser (traductor) chequea la consulta transmitida por el programa de aplicaci�n (cliente) para comprobar que la sintaxis es correcta y crear un �rbol de la consulta.

  3. El sistema de reescritura toma el �rbol de la consulta creado en el paso del traductor y busca reglas (almacenadas en los cat�logos del sistema) que pueda aplicarle al �rbol de la consulta y realiza las transformaciones que se dan en el/los cuerpo/s de la/s regla/s. Encontramos una aplicaci�n del sistema de reescritura en la realizaci�n de las vistas.

    Siempre que se realiza una consulta contra una vista (es decir, una tabla virtual), el sistema de reescritura reescribe la consulta del usuario en una consulta que accede a las tablas base dadas en la definici�n de la vista inicial.

  4. El planeador/optimizador toma el �rbol de la consulta (reescrita) y crea un plan de la consulta que ser� el input para el ejecutor.

    Hace esto creando previamente todas las posibles rutas que le conducen a un mismo resultado. Por ejemplo, si hay un �ndice en una relaci�n que debe ser comprobada, hay dos rutas para comprobarla. Una posibilidad es un simple barrido secuencial y la otra posibilidad es utilizar el �ndice. Luego se estima el coste de ejecuci�n de cada plan, y se elige y ejecuta el plan m�s r�pido.

  5. El ejecutor realiza de modo recursivo el �rbol del plan y recupera tuplas en la forma representada en el plan. El ejecutor hace uso del sistema de almacenamiento mientras est� revisando las relaciones, realiza ordenaciones (sorts) y joins, eval�a cualificaciones y finalmente devuelve las tuplas derivadas.

En las siguientes secciones, cubriremos todos los pasos listados antes en m�s detalle, para dar un mejor conocimiento de las estructuras de datos y de control interno de Postgres.