Background: #252 fixed aggregate filters being silently dropped by routing all filtered aggregates through an Elixir-side evaluation path (Ash.Filter.Runtime.filter_matches). This is correct and complete but loads more data from Neo4j than necessary.
Opportunity: For the common case — a filter on a scalar property of the destination node using a simple operator (==, !=, <, >, in, is_nil, contains) — the filter can be expressed as a WHERE clause after the OPTIONAL MATCH in the Cypher query, avoiding the need to load and evaluate records in Elixir.
Proposed approach: Inspect aggregate.filter at query-build time. If it reduces to a simple condition (or conjunction of simple conditions) on destination node properties, emit a Cypher WHERE clause. Fall back to the existing Elixir-side path for anything more complex.
Acceptance criteria: Existing #252 tests continue to pass. Benchmark shows reduced data transfer for the simple-filter case. Behaviour is identical for complex filters.
Background: #252 fixed aggregate filters being silently dropped by routing all filtered aggregates through an Elixir-side evaluation path (Ash.Filter.Runtime.filter_matches). This is correct and complete but loads more data from Neo4j than necessary.
Opportunity: For the common case — a filter on a scalar property of the destination node using a simple operator (==, !=, <, >, in, is_nil, contains) — the filter can be expressed as a WHERE clause after the OPTIONAL MATCH in the Cypher query, avoiding the need to load and evaluate records in Elixir.
Proposed approach: Inspect aggregate.filter at query-build time. If it reduces to a simple condition (or conjunction of simple conditions) on destination node properties, emit a Cypher WHERE clause. Fall back to the existing Elixir-side path for anything more complex.
Acceptance criteria: Existing #252 tests continue to pass. Benchmark shows reduced data transfer for the simple-filter case. Behaviour is identical for complex filters.