Unterstützt Postgresql plpgsql/sql in der Where-Klausel einen Kurzschluss?

Question

Wenn ich habe folgendes Spielzeug Abfrage

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; 

Würde die erste Bedingung in dem Kurzschluss WHERE-Klausel der zweite Bedingung, die eine komplexe Laufzeit haben würde?

Ich arbeite an einigen SQL, die tatsächlich Teil eines FOR LOOP in Plpgsql ist, und ich könnte Iterationen über alle Datensätze, die in den my_other_tables existieren, und dann im Rahmen der FOR LOOP mit der some_slow_func (). Aber ich bin gespannt, ob SQL unterstützt, oder plpgsql unterstützt Kurzschlüsse.

Einige Forschung: sah ich in den Postgres Mailinglisten und fand dies im allgemeinen sagen, SQL nicht Kurzschlüsse unterstützt:

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

Aber eine der Antworten sagt, dass, um durch durchgesetzt werden kann Subselects. Ich bin mir nicht sicher, wovon er spricht. Ich weiß, was ein Subselect ist, aber ich bin mir nicht sicher, wie die Order durchgesetzt wird. Könnte jemand das für mich klären?

Answer 1

Wie dokumentiert, ist die Bewertungsreihenfolge in einer WHERE-Klausel nicht vorhersehbar.

Bei Unterabfragen ist das anders. Bei den aktuellen Versionen besteht die einfachste und gebräuchlichste Methode zur Steuerung der Evaluierungsreihenfolge darin, eine Unterabfrage in einem CTE zu schreiben. Um sicherzustellen, dass die IN(...) zuerst ausgewertet wird, könnte den Code geschrieben werden als:

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; 

etwas anderes, das Sie optimieren können, ist die Kosten Ihrer Funktion des Optimierer zu signalisieren, dass es langsam ist. Die Standardkosten für eine Funktion sind 100, und es kann wie mit einer Aussage geändert werden:

ALTER FUNCTION funcname(argument types) cost N; 

wo N ist die geschätzten per-Call-Kosten, in einer willkürlichen Einheit ausgedrückt, die die Planner Cost Constants verglichen werden soll.

Answer 2

Nach the Postgresql docs und this answer by Tom Lane, die Reihenfolge der Ausführung der WHERE Einschränkungen ist nicht zuverlässig.

Ich denke, Ihre beste Wette hier könnte sein, diesen anderen Teil Ihrer WHERE-Klausel an den Anfang Ihrer Funktion hinzuzufügen und "fail fast"; dh, führen Sie in Ihrer Funktion my_id in ( SELECT my_other_id FROM my_other_tables) aus, und wenn es nicht besteht, kehren Sie direkt dorthin zurück, bevor Sie intensiv arbeiten. Das sollte dir ungefähr den gleichen Effekt bringen.

Answer 3

Ich weiß, dass dies eine alte Frage ist, aber vor kurzem in ähnliches Problem lief, und die Verwendung eines CASE-Prädikat in der WHERE-Klausel funktionierte besser für mich. Im Zusammenhang mit der obigen Antwort:

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; 

Dies macht für SQL, die etwas mehr DB-agnostisch ist. Natürlich kann es keine Indizes verwenden, wenn Sie einige auf my_id haben, aber abhängig von dem Kontext, in dem Sie sich befinden, könnte dies eine gute Option sein.