zihaozeng0021 commented on issue #2288:
URL: https://github.com/apache/age/issues/2288#issuecomment-3693549991
Moreover, if you are willing to spend some time to try more cases, you would
find AGE *does* correctly short-circuit obviously-unsatisfiable predicates,
which suggests there is intentional constant folding / contradiction pruning
(either in AGE’s Cypher layer or in PostgreSQL planning).
For example, these cases all return immediately in AGE:
- `WHERE 1 = 2`
- `WHERE 1 <> 1`
- `WHERE 1 <> toInteger("1")`
- `WHERE 1 = NULL`
- `WHERE CASE 1 WHEN 1 THEN false ELSE true END`
- `WHERE "abc" CONTAINS "z"`
This is important because it shows the engine is capable of pruning “always
false” filters in some situations, but appears to miss (or be unable to
recognize) the cases I reported (e.g., self-inequality on `id(q)`,
contradictions introduced via aggregates like `count(q) < 0`, or null checks
after constructing maps).
---
In conclusion. Why would `WHERE id(q) <> id(q)` force a fundamentally
different execution path than `WHERE 1 <> 1`? I understand that `1` is a
literal (compile-time constant) while `id(q)` depends on a bound variable and a
function call, but both predicates are never logically satisfiable. both should
be safe enough to be treat as “never TRUE” and therefore short-circuitable. So
the large performance difference is hard for me to attribute to “just different
routes” alone — it looks more like a missing optimization or a
semantic/volatility constraint around `id()` that prevents the planner from
pruning.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
