Hace un por de semanas decidí instalar el motor de base de datos PostgresQL que está en desarrollo con el fin de revisar el código y determinar cuan difícil podría ser extender el comando EXPLAIN para que la salida tuviera la opción de ser en texto plano (tal cual es hoy en día) o en XML.
Para quien no esté enterado, EXPLAIN ANALYZE permite determinar el costo de ejecución de una consultar y ver como estructura la consulta el planificador de la base de datos. Por lo tanto, es muy importante para optimizar las consultas. Toda base de datos que se precie permite hacerlo. Claro que en otras bases de datos existen herramientas como el «Query Analyzer» (de MS SQL Server) que ofrece una interfaz gráfica para determinar los cuellos de botella de una consulta.
La idea de contar con una salida XML de la instrucción EXPLAIN es facilitar su procesamiento por otros programas sin tener que programar un analizador sintáctico específico para la salida de esta instrucción. Pensamos que al contar con mejores herramientas podríamos ayudar a disminuir las barreras de entrada que tiene PostgresQL, ya que facilita el trabajo de los desarrolladores que la emplean.
Denys desarrolló una herramienta que permite hacerlo visualmente. Pero requiere que la base de datos entregue el resultado de EXPLAIN en XML, lo cual ha hecho parchando el motor de la base de datos. Sin embargo, el parche de momento sirve como prueba de concepto y es necesario buscar una solución que permita que sea incluído en forma oficial, ya que envía tanto la salida de texto plano como XML en forma conjunta.
Es por eso que decidí revisar el código de la base de datos. Desde que lo instalé no lo había vuelto ver hasta hoy, que, motivado por Denys que me entregó su versión de explain.c decidí retomar mi incursión.
El código del motor es bastante ordenado y fácil de entender. Esperaba que tardara varias horas en compilar, y tardó menos de 4 minutos en Centrino de 1.8 Ghz. Así, mientras controlaba un certamen, compilé la última versión del CVS, analice las diferencias de la versión de Denys (que trabajó sobre la versión de noviembre del año pasado) y añadí lo necesario en el analizador sintáctico para que reconozca correctamente la sintáxis deseada, así como en el psql. Todo sin haber visto antes el código de PostgresQL. Simplemente para ilustrar lo ordenado y claro que es.
Ahora me resta trabajar en lo esencial del parche. Aunque ya estoy viendo que el enfoque para resolverlo podría ser un poco distinto al original y de acuerdo la alternativa elegida entre las cuatro que me imaginaba.
Por cierto, siempre es bueno tener un hacker de PostgresQL de cabecera, a quién pedirle consejos de implementación :-)