Zamieszanie wokół LEFT JOIN i WHERE klauzula była wielokrotnie wyjaśniana:
To interesujące pytanie pozostaje:
W Postgresie nie ma wyraźnych wskazówek dotyczących zapytań. (Co jest przedmiotem toczącej się debaty). Ale wciąż istnieją różne sztuczki, które sprawią, że Postgres pochyli się na twojej drodze.
Ale najpierw zadaj sobie pytanie: Dlaczego planer zapytań oszacował, że wybrany plan jest na początku tańszy? Czy konfiguracja twojego serwera jest w zasadzie rozsądna? Czy ustawienia kosztów są odpowiednie? autovacuum działanie? Wersja Postgresa jest nieaktualna? Czy rozwiązujesz podstawowy problem, który naprawdę powinien zostać naprawiony?
Jeśli zmusisz Postgresa, aby zrobił to po swojemu, powinieneś mieć pewność, że nie odpali się po aktualizacji wersji lub aktualizacji konfiguracji serwera ... Lepiej wiedzieć, co dokładnie robisz.
To powiedziawszy, możesz zmusić Postgres do "odfiltrowania niektórych rekordów przed wykonaniem JOIN z podzapytaniem, w którym dodajesz OFFSET 0 - co logicznie jest tylko szumem, ale zapobiega przekształceniu go przez Postgres w formę zwykłego sprzężenia. (W końcu podpowiedź do zapytania)
SELECT la.listing_id, la.id, lar.*
FROM (
SELECT listing_id, id
FROM la
WHERE listing_id = 2780
OFFSET 0
) la
LEFT JOIN lar ON lar.application_id = la.id;
Możesz też użyć CTE (mniej niejasny, ale droższy). Lub inne sztuczki, takie jak ustawianie pewnych parametrów konfiguracyjnych. Lub, w tym konkretnym przypadku, użyłbym LATERAL dołącz do tego samego efektu:
SELECT la.listing_id, la.id, lar.*
FROM la
LEFT JOIN LATERAL (
SELECT *
FROM lar
WHERE application_id = la.id
) lar ON true
WHERE la.listing_id = 2780;
Powiązane:
Oto obszerny blog na temat wskazówek dotyczących zapytań autorstwa 2ndQuadrant. Pięć lat, ale nadal ważny.
