Wenn in Datenbankabfragen Prädikate verwendet werden, die niemals wahr sein können (z.B. „Datum >= 2015-01-01 AND Datum < 2015-01-01“ oder „1 = 2“) erkennt der Oracle Optimizer diesen Wiederspruch und generiert für den Betroffenen Ast des Ausführungsplans einen Filter mit dem Prädikat „NULL IS NOT NULL“. Dieser Ast des Ausführungsplans wird dann bei der Ausführung des Plans schlicht nicht ausgeführt. Unabhängig hiervon zeigt der Optimizer jedoch trotzdem die Kosten und Kardinalität der Schritte im entsprechenden Ast, als wenn diese normal ausgeführt würden, an. Das kann leicht zur fälschlichen Annahme führen, dass die Operationen in diesem Ast des Ausführungsplans tatsächlich ausgeführt werden. In Wahrheit wird der gesamte Zweig jedoch von der Execution-Engine nicht ausgeführt, wodurch er real auch keine Kosten verursacht. 
Execution Plan mit Filter Null is not Null Bei Microsoft SQL Server ist dies anders gelöst, hier wird im Ausführungsplan ein Constant Scan angezeigt. Der Constant Scan Operator gibt eine statische Anzahl Zeilen zurück, die bereits bei der Erstellung des Plans definiert wurde. Im Fall von Prädikaten die immer falsch ergeben (Falsy Predicates) gibt der Constant Scan 0 Zeilen, also eine leere Menge zurück. 
Execution Plan mit Constant Scan Der Effekt, dass ein Teil der Abgefragten Tabellen bei der Ausführung nicht gelesen wird ist in Oracle und SQL Server der gleiche. Jedoch unterschiedlichen realisiert: Beide erkennen im Optimizer bereits die widersprüchlichen Prädikate die niemals zutreffen können. SQL-Server nutzt einen speziellen Plan-Operator über den bereits im Plan sehr klar ersichtlich ist, dass hier kein Aufwand entsteht. In den Ausführungsplänen von Oracle (zumindest bis 11g R2) ist dies nicht so offensichtlich zu erkennen, insbesondere die Kosten im Ausführungsplan können hier leicht in die Irre führen. Aber am Filter mit der Bedingung NULL IS NOT NULL kann man dies auch bei Oracle im Ausführungsplan zuverlässig erkennen. Man muss nur auf dieses Detail achten. Bleibt noch die Frage: Wieso sollte man solche Prädikate in einer Abfrage verwenden? Ein Beispiel hierfür sind automatische Verarbeitungsprozesse die in einem gewissen Zeitraum angelegten Daten aus mehreren Tabellen lesen und verarbeiten. Möchte man nun die Verarbeitung der Daten einzelner Tabellen aussetzen ohne die Verarbeitung anzupassen kann man schlicht für Beginn und Ende des zu verarbeitenden Zeitraums das gleiche Datum einsteuern und der SQL-Optimizer sorgt dafür, dass nichts abgefragt und damit auch nichts verarbeitet wird.