De reden dat u een verschil ziet, is te wijten aan het uitvoeringsplan dat de planner samenstelt, dit is duidelijk anders, afhankelijk van de query (misschien zou het de 2 query's moeten optimaliseren om hetzelfde te zijn en dit kan een bug zijn ). Dit betekent dat de planner denkt dat hij op een bepaalde manier moet werken om bij elke stelling tot het resultaat te komen.
Wanneer je dit doet binnen de JOIN, zal de planner waarschijnlijk uit de tabel moeten selecteren, filteren op het gedeelte "True" en vervolgens de resultatensets samenvoegen. Ik kan me voorstellen dat dit een grote tabel is, en daarom veel gegevens om door te bladeren, en het kan de indexen niet zo efficiënt gebruiken.
Ik vermoed dat als je het in een WHERE-clausule doet, de planner een route kiest die efficiënter is (dwz een op index gebaseerde of voorgefilterde dataset).
U kunt de samenvoeging waarschijnlijk net zo snel (zo niet sneller) laten werken door een index toe te voegen aan de twee kolommen (niet zeker of opgenomen kolommen en meerdere kolomindexen al worden ondersteund op Postgres).
Kortom, de planner is het probleem, hij kiest 2 verschillende routes om bij de resultatensets te komen, en de ene is niet zo efficiënt als de andere. Het is voor ons onmogelijk om te weten wat de redenen zijn zonder de volledige tabelinformatie en de EXPLAIN ANALYZE-informatie.
Als u wilt weten waarom uw specifieke zoekopdracht dit doet, moet u meer informatie verstrekken. De reden is echter dat de planner verschillende routes kiest.
Aanvullend leesmateriaal:
http://www.postgresql.org/docs/current/static/explicit-joins.html
Even geskimd, het lijkt erop dat de postgres-planner de joins niet opnieuw bestelt om het te optimaliseren. probeer de volgorde van de joins in je statement te veranderen om te zien of je dan dezelfde prestatie krijgt... slechts een gedachte.