La razón por la que está viendo una diferencia se debe al plan de ejecución que está elaborando el planificador, esto obviamente es diferente según la consulta (posiblemente, debería estar optimizando las 2 consultas para que sean iguales y esto puede ser un error ). Esto significa que el planificador piensa que tiene que trabajar de una manera particular para llegar al resultado de cada enunciado.
Cuando lo haga dentro de JOIN, el planificador probablemente tendrá que seleccionar de la tabla, filtrar por la parte "Verdadero" y luego unir los conjuntos de resultados. Me imagino que esta es una tabla grande y, por lo tanto, una gran cantidad de datos para revisar, y no puede usar los índices de manera tan eficiente.
Sospecho que si lo hace en una cláusula WHERE, el planificador está eligiendo una ruta que es más eficiente (es decir, un conjunto de datos basado en índice o prefiltrado).
Probablemente podría hacer que la unión funcione tan rápido (si no más rápido) agregando un índice en las dos columnas (no estoy seguro si las columnas incluidas y los índices de columnas múltiples son compatibles con Postgres todavía).
En resumen, el planificador tiene el problema de elegir 2 rutas diferentes para llegar a los conjuntos de resultados, y una de ellas no es tan eficiente como la otra. Es imposible para nosotros saber cuáles son los motivos sin la información completa de la tabla y la información EXPLAIN ANALYZE.
Si desea obtener detalles sobre por qué su consulta específica está haciendo esto, deberá proporcionar más información. Sin embargo, la razón es que el planificador elige rutas diferentes.
Material de lectura adicional:
http://www.postgresql.org/docs/current/static/explicit-joins.html
Recién hojeado, parece que el planificador de postgres no reordena las uniones para optimizarlo. intente cambiar el orden de las uniones en su declaración para ver si luego obtiene el mismo rendimiento... solo una idea.
