Query Results (meta-source)

Query Results is a meta-source, not a real database connection — every organization gets it automatically, with nothing to configure and no credentials to enter. It exists to answer one question SQL normally can’t: how do you join data that lives in two different connectors?

How it works

Reference a previously-run query’s cached result as a table named query_<id>, where <id> is that query’s numeric id — then write ordinary SQL against it, including joining several of these “query tables” together:

SELECT o.*, u.name
FROM query_42 o
JOIN query_17 u ON u.id = o.user_id

Behind the scenes, arcodash loads each referenced query’s most recent cached result into an in-memory SQLite database and runs your SQL against that. This is why the join above works even if query_42 originally ran against Postgres and query_17 ran against a completely unrelated warehouse — by the time your SQL runs, both are just tables in the same temporary SQLite instance.

[!NOTE] Because the join happens in SQLite, the SQL dialect that applies is SQLite’s — not whatever dialect either underlying query’s own connector speaks. Functions or syntax specific to Postgres, MySQL, etc. won’t necessarily work here even if the source query used them.

You’re querying a cache, not live data

This is the most important caveat: query_<id> reflects that query’s last cached result, not a live read of its underlying source. If the underlying query hasn’t been run again since data changed at the source, this meta-source won’t reflect that change until the underlying query runs again (manually, or on its own schedule).

[!TIP] If a dashboard built on Query Results looks stale, check when the underlying queries it references last ran — refreshing the dashboard itself doesn’t re-run them; only running the original queries again refreshes what’s available to join against here.

Limits worth knowing

• Only the single most recent cached result per distinct query is available — not history.
• A query whose result has never been cached (or whose cache was cleared) doesn’t show up as a query_<id> table at all; run it at least once first.
• At most 500 distinct cached results are loaded into the in-memory database per run — not necessarily the 500 most recently run ones — so an organization with more than 500 queries that have a cached result may not have every one of them available to reference at once.

Where to go next

• Connectors overview — creating and managing the real connections whose results you can later join with this meta-source.