A razão pela qual você está vendo uma diferença é devido ao plano de execução que o planejador está montando, isso é obviamente diferente dependendo da consulta (sem dúvida, deve estar otimizando as 2 consultas para serem iguais e isso pode ser um bug ). Isso significa que o planejador pensa que tem que trabalhar de uma maneira particular para chegar ao resultado em cada declaração.

Quando você fizer isso dentro do JOIN, o planejador provavelmente terá que selecionar na tabela, filtrar pela parte "True" e juntar os conjuntos de resultados. Eu imagino que esta é uma tabela grande e, portanto, muitos dados para examinar e não pode usar os índices com a mesma eficiência.

Eu suspeito que se você fizer isso em uma cláusula WHERE, o planejador está escolhendo uma rota que é mais eficiente (ou seja, com base em índice ou conjunto de dados pré-filtrado).

Você provavelmente poderia fazer a junção funcionar tão rápido (se não mais rápido) adicionando um índice nas duas colunas (não tenho certeza se colunas incluídas e vários índices de coluna ainda são suportados no Postgres).

Resumindo, o planejador tem o problema de escolher 2 rotas diferentes para chegar aos conjuntos de resultados, e uma delas não é tão eficiente quanto a outra. É impossível para nós saber quais são os motivos sem as informações completas da tabela e as informações EXPLAIN ANALYZE.

Se você quiser detalhes sobre por que sua consulta específica está fazendo isso, será necessário fornecer mais informações. No entanto, o motivo é o planejador escolher rotas diferentes.

Material de leitura adicional:

http://www.postgresql.org/docs/current/static/explicit-joins.html

Apenas desnatado, parece que o planejador do postgres não reordena as junções para otimizá-lo. tente alterar a ordem das junções em sua declaração para ver se você obtém o mesmo desempenho ... apenas um pensamento.