Powodem, dla którego widzisz różnicę, jest plan wykonania, który planista zestawia, jest to oczywiście różne w zależności od zapytania (prawdopodobnie powinno być zoptymalizowanie 2 zapytań, aby były takie same i może to być błąd ). Oznacza to, że planista uważa, że musi działać w określony sposób, aby uzyskać wynik w każdym stwierdzeniu.
Kiedy zrobisz to w ramach JOIN, planista prawdopodobnie będzie musiał wybrać z tabeli, przefiltrować według części „Prawda”, a następnie połączyć zestawy wyników. Wyobrażam sobie, że jest to duża tabela, a zatem dużo danych do przejrzenia, i nie może używać indeksów tak wydajnie.
Podejrzewam, że jeśli zrobisz to w klauzuli WHERE, planista wybiera trasę, która jest bardziej wydajna (tj. oparta na indeksie lub wstępnie przefiltrowanym zbiorze danych).
Prawdopodobnie możesz sprawić, by łączenie działało tak szybko (jeśli nie szybciej), dodając indeks na dwóch kolumnach (nie jesteś pewien, czy dołączone kolumny i indeksy wielu kolumn są jeszcze obsługiwane w Postgresie).
Krótko mówiąc, problem polega na tym, że planista wybiera 2 różne trasy, aby dostać się do zestawów wyników, a jedna z nich nie jest tak wydajna jak druga. Nie jesteśmy w stanie wiedzieć, jakie są przyczyny bez pełnej informacji w tabeli i informacji WYJAŚNIJ ANALIZĘ.
Jeśli chcesz uzyskać szczegółowe informacje na temat przyczyny tego konkretnego zapytania, musisz podać więcej informacji. Jednak powodem jest to, że planista wybiera różne trasy.
Dodatkowe materiały do czytania:
http://www.postgresql.org/docs/current/static/explicit-joins.html
Wystarczy przejrzeć, wydaje się, że planista postgres nie zmienia kolejności złączeń, aby je zoptymalizować. spróbuj zmienić kolejność złączeń w swoim oświadczeniu, aby sprawdzić, czy uzyskasz taką samą wydajność... tylko myśl.
