De todos los operadores relacionales, el más difícil de procesar y optimizar es el join (unión). El número de planes de consulta posibles crece exponencialmente con el número de joins en la consulta. Un esfuerzo adicional de optimización es causado por el soporte de una variedad de métodos de join (por ejemplo, nested loop, hash join, merge join en PostgreSQL) para procesar joins individuales y una diversidad de índices (por ejemplo, B-tree, hash, GiST y GIN en PostgreSQL) como rutas de acceso para las relaciones.

El optimizador de consultas normal de PostgreSQL realiza una búsqueda casi exhaustiva sobre el espacio de estrategias alternativas. Este algoritmo, introducido por primera vez en la base de datos System R de IBM, produce un orden de join casi óptimo, pero puede consumir una cantidad enorme de tiempo y espacio de memoria cuando el número de joins en la consulta aumenta. Esto hace que el optimizador de consultas ordinario de PostgreSQL sea inadecuado para consultas que unen una gran cantidad de tablas.

El Instituto de Control Automático de la Universidad de Minería y Tecnología en Freiberg, Alemania, se enfrentó a algunos problemas cuando quiso utilizar PostgreSQL como motor de base de datos para un sistema basado en conocimiento para el soporte de decisiones en el mantenimiento de una red de energía eléctrica. El DBMS necesitaba manejar consultas complejas con muchos joins para el motor de inferencia del sistema basado en conocimiento. El número de joins en estas consultas hacía inviable el uso del optimizador de consultas normal.

A continuación, describimos la implementación de un algoritmo genético para resolver el problema del ordenamiento de joins de una manera eficiente para consultas que involucran una gran cantidad de joins.