Computed Tables FAQ
Referencing and Joins
Can a Computed Table reference another Computed Table?
No. Computed Tables are stored as metadata inside Qualytics; they are not created as real views or tables in the warehouse. When the warehouse runs the query, it cannot resolve a Computed Table by name. If you need to chain logic, merge the intermediate step into a single query using a CTE (WITH ... AS (...)), or materialize the intermediate result as a real view or table in the warehouse and catalog it in Qualytics.
Can a Computed Table join tables from different datastores?
No. A Computed Table only sees the base tables and views of its own parent datastore. For cross-datastore joins, use a Computed Join.
Can I use a Computed Table as an input to a Computed Join?
Yes. A Computed Join can be built on top of tables, views, Computed Tables, or Computed Files as long as each input has been profiled. The only input a Computed Join cannot accept is another Computed Join.
Materialization and Cost
Are Computed Tables materialized in the warehouse?
No. The SQL query is stored as metadata inside Qualytics and executed against the live warehouse every time the container is scanned, profiled, or previewed. Nothing is written back to the warehouse.
Does saving a Computed Table trigger a scan?
No. Saving persists the definition and runs a basic profile that samples up to 1000 records per partition so field statistics appear immediately. A full profile and any scans run only when you or a schedule kick them off.
How can I reduce the cost of a slow Computed Table?
The query runs every time the container is scanned or profiled, so slow queries scale their cost with scan frequency. To speed things up: narrow with a WHERE clause, use warehouse-native indexes and materialized views for heavy joins, and consider moving very heavy preparation into a real warehouse view that Qualytics catalogs as a base container.
Connector Behavior
Why does my SQL Server / Oracle / Redshift query fail with "table not found"?
These connectors require fully-qualified names. Table names dropped from the modal's picker are already prefixed with the datastore's schema. If you hand-type a reference (or point to a table in a different schema), qualify it explicitly as SCHEMA.TABLE in the query body.
Where does the Computed Table SQL execute?
In the parent warehouse. Qualytics sends the SQL to the datastore's JDBC connection and treats the returned rows as the container's data. Write the query in whichever dialect the warehouse expects (Oracle SQL for Oracle, T-SQL for SQL Server, Redshift SQL for Redshift, Snowflake SQL for Snowflake, and so on). This is different from Computed Files, which run through Qualytics's own analytical engine.
Editing and History
Does editing the query re-run the profile?
Yes. Saving an edit immediately triggers a synchronous slim profile so field statistics refresh right away, followed by a full asynchronous profile. Existing quality checks are preserved, and anomalies raised against the older version remain in the anomaly history.
Can I see previous versions of the query?
Yes. Open the container's History panel to see the timeline of query changes. Each entry has a View Query Changes action that opens a From/To dialog highlighting what was added and removed, along with the user and timestamp for that change.
Permissions
Who can create a Computed Table?
Any user with the Editor or Author team permission on the parent datastore. Authors can only create Computed Tables they own themselves; Editors can create Computed Tables owned by any user.
Who can reassign ownership?
Only users with the Editor team permission. Authors cannot change the owner of a Computed Table, even one they own.