SARGable Filtering in Query Activities
Filter large tables without forcing unnecessary scans.
Evidence tier describes my hands-on relationship with the content. Official sources describe platform contracts/documentation. Production observations should not automatically be treated as official limits.
On large Data Extensions and Data Views, where the function is applied can decide whether the database can use an index efficiently. Keep searchable columns “bare” on the left side of predicates whenever possible.
Prefer EventDate >= DATEADD(...) over DATEDIFF(..., EventDate, ...).
Filter early before expensive joins.
Restrict the time window before aggregation when the use case allows it.
Recurring timeouts require redesign, not infinite retries.
Prefer this
The database can compare EventDate directly against one calculated boundary.
WHERE EventDate >= DATEADD(day, -30, GETDATE())
Avoid this on large sources
Wrapping the source column in a function can prevent efficient index use and force much more work.
WHERE DATEDIFF(day, EventDate, GETDATE()) <= 30
Salesforce specifically calls out non-SARGable predicates as a common Query Activity timeout cause.
Filter before you join
If you only need 30 days of opens, constrain _Open before letting it participate in a large relationship graph. Intermediate tables are often cleaner than asking one query to do everything.