La raison pour laquelle vous voyez une différence est due au plan d'exécution que le planificateur met en place, c'est évidemment différent selon la requête (sans doute, il devrait optimiser les 2 requêtes pour qu'elles soient identiques et cela peut être un bogue ). Cela signifie que le planificateur pense qu'il doit travailler d'une manière particulière pour arriver au résultat dans chaque instruction.
Lorsque vous le faites dans le JOIN, le planificateur devra probablement sélectionner dans le tableau, filtrer par la partie "True", puis joindre les ensembles de résultats. J'imagine qu'il s'agit d'une grande table, et donc de beaucoup de données à parcourir, et qu'elle ne peut pas utiliser les index aussi efficacement.
Je soupçonne que si vous le faites dans une clause WHERE, le planificateur choisit un itinéraire plus efficace (c'est-à-dire basé sur un index ou un ensemble de données préfiltré).
Vous pourriez probablement rendre la jointure aussi rapide (sinon plus rapide) en ajoutant un index sur les deux colonnes (vous ne savez pas si les colonnes incluses et les index de colonnes multiples sont encore pris en charge sur Postgres).
En bref, le problème du planificateur est de choisir 2 itinéraires différents pour accéder aux ensembles de résultats, et l'un d'entre eux n'est pas aussi efficace que l'autre. Il nous est impossible de connaître les raisons sans les informations complètes du tableau et les informations EXPLAIN ANALYZE.
Si vous voulez des détails sur la raison pour laquelle votre requête spécifique fait cela, vous devrez fournir plus d'informations. Cependant, la raison en est que le planificateur choisit des itinéraires différents.
Matériel de lecture supplémentaire :
http://www.postgresql.org/docs/current/static/explicit-joins.html
Juste écrémé, il semble que le planificateur de postgres ne réorganise pas les jointures pour l'optimiser. essayez de changer l'ordre des jointures dans votre déclaration pour voir si vous obtenez ensuite les mêmes performances... juste une réflexion.
