Czy Postgresql plpgsql/sql obsługuje zwarcie w klauzuli where?

Question

Jeśli mam następujące zapytanie zabawka

SELECT * 
FROM my_tables 
WHERE my_id in (
    SELECT my_other_id 
    FROM my_other_tables 
) AND some_slow_func(arg) BETWEEN 1 AND 2; 

Czy pierwszy warunek w klauzuli WHERE zwarcia drugi warunek, które mają złożoną czas pracy?

Pracuję nad pewnym sql, który jest faktycznie częścią FOR LOOP w plpgsql, i mógłbym zrobić iteracje nad wszystkimi rekordami istniejącymi w my_other_tables, a następnie przetestować w ramach FOR LOOP z some_slow_func (). Ale jestem ciekawy, czy obsługuje sql, lub plpgsql obsługuje zwarcie.

rozeznanie: Spojrzałem na listach dyskusyjnych PostgreSQL oraz SQL, które oceniły tę mówiąc w ogóle nie obsługuje zwarcia:

http://www.postgresql.org/message-id/171423D4-9229-4D56-B06B-58D29BB50A77@yahoo.com

Ale jedną z odpowiedzi mówi, że zamówienie może być egzekwowane przez subselects. Nie jestem do końca pewien, o czym on mówi. Wiem, co to jest selekcja podrzędna, ale nie jestem pewien, w jaki sposób będzie egzekwowane zamówienie? Czy ktoś może mi to wyjaśnić?

Answer 1

Zgodnie z dokumentacją, kolejność oceny w klauzuli WHERE ma być nieprzewidywalna.

Różni się w przypadku podkwerend. W aktualnych wersjach najprostszą i powszechną metodą sterowania kolejnością oceny jest zapisanie podkwerendy w CTE. Aby upewnić się, że IN(...) ocenia najpierw, kod może być zapisany jako:

WITH subquery AS 
(select * from my_tables 
    WHERE my_id in (SELECT my_other_id FROM my_other_tables) 
) 
SELECT * FROM subquery 
    WHERE some_slow_func(arg) BETWEEN 1 AND 2; 

coś innego, że można dostosować to koszt swojej funkcji, aby zasygnalizować, że optymalizator jest powolne. Koszt domyślną funkcją jest 100 i może być zmieniony z oświadczeniem, takich jak:

ALTER FUNCTION funcname(argument types) cost N; 

gdzie N jest szacunkowy koszt wezwanie, wyrażone w dowolnej jednostce, która powinna być w porównaniu do Planner Cost Constants.

Answer 2

Zgodnie z the Postgresql docs i this answer by Tom Lane kolejność wykonywania ograniczeń WHERE nie jest wiarygodna.

Myślę, że najlepiej będzie dodać drugą część WHERE do górnej części swojej funkcji i "szybko zawieść"; tj. uruchom my_id in ( SELECT my_other_id FROM my_other_tables) w swojej funkcji, a jeśli nie przejdzie, wróć tutaj, zanim wykonasz intensywne przetwarzanie. To powinno dać ci mniej więcej taki sam efekt.

Answer 3

Wiem, że to stare pytanie, ale ostatnio wpadł na podobny problem, a znalezione przy użyciu predykatu CASE w klauzuli WHERE działało lepiej dla mnie. W kontekście powyższej odpowiedzi:

SELECT * 
    FROM my_tables 
WHERE CASE WHEN my_id in (SELECT my_other_id 
          FROM my_other_tables) 
      AND some_slow_func(arg) BETWEEN 1 AND 2 
      THEN 1 
      ELSE 0 
     END = 1; 

To sprawia, że ​​SQL jest nieco bardziej agnostyczny. Oczywiście, może nie używać indeksów, jeśli masz trochę na my_id, ale w zależności od kontekstu, w którym się znajdujesz, może to być dobra opcja.