Der Grund, warum Sie einen Unterschied sehen, liegt an dem Ausführungsplan, den der Planer zusammenstellt. Dies ist offensichtlich je nach Abfrage unterschiedlich (es sollte wohl die beiden Abfragen so optimieren, dass sie gleich sind, und dies kann ein Fehler sein ). Das bedeutet, dass der Planer denkt, dass er auf eine bestimmte Weise arbeiten muss, um in jeder Anweisung zum Ergebnis zu gelangen.
Wenn Sie dies innerhalb des JOINs tun, muss der Planer wahrscheinlich aus der Tabelle auswählen, nach dem „True“-Teil filtern und dann die Ergebnismengen verbinden. Ich würde mir vorstellen, dass dies eine große Tabelle ist und daher viele Daten zu durchsuchen sind und die Indizes nicht so effizient verwendet werden können.
Ich vermute, dass der Planer eine effizientere Route wählt, wenn Sie dies in einer WHERE-Klausel tun (dh entweder indexbasiert oder vorgefilterter Datensatz).
Sie könnten die Verknüpfung wahrscheinlich genauso schnell (wenn nicht schneller) machen, indem Sie einen Index für die beiden Spalten hinzufügen (nicht sicher, ob eingeschlossene Spalten und mehrere Spaltenindizes von Postgres noch unterstützt werden).
Kurz gesagt, der Planer ist das Problem, dass er zwei verschiedene Routen auswählt, um zu den Ergebnismengen zu gelangen, und eine davon ist nicht so effizient wie die andere. Ohne die vollständigen Tabelleninformationen und die EXPLAIN ANALYZE-Informationen können wir die Gründe nicht ermitteln.
Wenn Sie Einzelheiten dazu wünschen, warum Ihre spezifische Abfrage dies tut, müssen Sie weitere Informationen bereitstellen. Der Grund ist jedoch, dass der Planer andere Routen wählt.
Zusätzliches Lesematerial:
http://www.postgresql.org/docs/current/static/explicit-joins.html
Nur überflogen, scheint, dass der Postgres-Planer Joins nicht neu anordnet, um ihn zu optimieren. Versuchen Sie, die Reihenfolge der Verknüpfungen in Ihrer Anweisung zu ändern, um zu sehen, ob Sie dann die gleiche Leistung erhalten ... nur ein Gedanke.
