Skip to content

Cost and Performance

A Computed Table is metadata; nothing is materialized in the warehouse. Every operation that needs to look at the container (a profile, a scan, a quality check run, a preview) executes the stored query against the parent JDBC datastore's connection. This page walks through where the cost lives, how to spot slow queries early, and when to move logic out of the Computed Table entirely.

Where the Cost Lives

Each of these operations runs the full query end-to-end against the warehouse:

  • Scans: every quality check on the Computed Table triggers a full read.
  • Full profile: every field's statistics are recomputed from the current query result.
  • Preview: the Container detail view samples rows from a live query.

Validation is different. Validate is a schema-only check: it parses the SQL and verifies every referenced object exists in the warehouse catalog, but it does not read production data. Validate is cheap and safe to run frequently while iterating on a query.

Signs a Computed Table Is Getting Slow

  • The slim profile that runs on Create or Edit takes longer than a few seconds.
  • Validate hits its timeout window and returns 408 Request Timeout.
  • Scheduled datastore profiles run past their usual window.
  • Individual scans stretch or fail with warehouse timeouts.

Ways to Cut Cost

  • Narrow with a WHERE clause. Filtering out rows that never contribute to anomalies is the highest-impact change you can make.
  • Push aggregations into the warehouse. A Computed Table like SELECT customer_id, SUM(amount) FROM orders GROUP BY customer_id runs the aggregation on every scan. Moving the same query into a real view (or materialized view) in the warehouse lets the warehouse's own refresh mechanism absorb the cost.
  • Use warehouse indexes and clustering. Every JDBC warehouse supports some form of index, partition, or clustering hint. Computed Tables inherit those benefits because the query runs directly against the warehouse's own query planner.
  • Enable incremental profiling. For very large Computed Tables with a timestamp or batch column, incremental profiling reads only the rows that changed since the last run. See Incremental Profiling.

When to Materialize Instead

If a Computed Table is:

  • reused across multiple quality checks or downstream reports,
  • expensive to compute (heavy joins, window functions, or aggregations over billions of rows), and
  • based on data that changes on a predictable schedule,

it is usually cheaper to build a real view or table in the warehouse itself, catalog it as a base container in Qualytics, and let the warehouse's own refresh mechanism run the transformation. The trade-off is that the warehouse view has to be refreshed by someone outside Qualytics; for logic that changes often or is unique to Qualytics's monitoring flow, a Computed Table is usually the right home.