204 - Trino Query: analytics and insights

If any term in this lesson feels unfamiliar, the 100 series is one click back. The 200 series assumes that mental model.

Trino is a distributed SQL engine that federates queries across many backends. Plexara uses Trino as the single execution layer every MCP data question passes through. Whether the underlying store is PostgreSQL, OpenSearch, Oracle, Snowflake, or any other Trino-compatible connector, the agent writes SQL once and Trino routes it to the right catalog.

The practical benefit: the agent does not have to learn half a dozen dialects. The customer does not have to standardize on a single vendor. The Plexara MCP server does not need to know, in advance, which kinds of stores it will end up talking to.

Every Trino table has a corresponding DataHub entity, keyed by URN. The URN includes the Trino catalog, schema, and table, which lets the agent go from a query result back to the catalog's owners, tags, glossary terms, lineage, and curated queries for that entity. This mapping is what makes a query result interpretable, not just readable. It is also what lets the enrichment described in the previous lesson attach automatically.

A frontier model already knows how to write SQL. That capability is in the training data. What it does not know, on its own, is your schema, your naming conventions, your glossary, or which column actually stores the number you care about. Plexara supplies that context, which is why agent-authored queries on a Plexara session tend to be correct on the first try rather than after three rounds of iteration.

Within any given session, a query can originate from one of three sources. All three are legitimate; which one runs depends on what the question is and what the catalog already knows.

If the frontier model can write SQL, it is reasonable to ask why a catalog of curated queries exists at all. Two answers. One is reproducibility, which matters most for anything that will be reported upward or referenced later. The other answer is less obvious but more important over time: a curated query is itself a layer of documentation.

The most common cause of a slow Plexara session is running the wrong shape of query against the wrong kind of store. Point lookups belong on row-oriented indexed stores; aggregations belong on columnar analytical stores. Running either against the wrong backend is where eighty-second queries come from, and the agent has no way to recover from a bad shape without rewriting the query.

The operating manual the agent receives from platform_info tells it which catalog is appropriate for which shape. A deployment whose OLAP layer is OpenSearch has that documented; a deployment that uses ClickHouse or Snowflake instead has its own version of the same guidance. The agent does not have to guess; it reads the manual.

When Trino can push an operation down to the underlying backend, it runs the operation natively and returns only the result. When it cannot push down, it reads rows back through the network and aggregates in-memory. For small tables this does not matter; for large tables it is the difference between a one-second query and a ninety-second one.

Some connectors expose escape hatches for cases where standard Trino SQL will not push down cleanly. The OpenSearch connector exposes a raw_query table function that lets the agent compose native OpenSearch Query DSL for aggregations. The customer's agent_instructions describe which escape hatches are appropriate for which backend; the benchmarks are measured, not assumed.

Not every query returns a handful of rows. Some return thousands. Getting the result shape right at query time, and choosing between trino_query and trino_export, is the difference between an efficient session and one that exhausts its context window on a single lookup.

Curated queries are often thought of as something the organization must preload into the catalog. In practice the flow is bidirectional. An agent that writes a new or derivative query during a session can surface it as an insight, and an administrator can promote it through the review pipeline into a catalog-level curated template. The next person asking a similar question gets that query handed to them by datahub_get_queries.

This matters for organizations starting from scratch. A customer with no curated queries on day one is not missing anything; the curated library builds itself from real usage. Every useful question the agent answers is a candidate future template.

Queries produce results. Small results live in the conversation. Large results, and anything worth keeping past the current session, belong in an asset. The next lesson covers the asset system.

Nine terms cover the vocabulary you will see across Trino results, the operating manual, and any discussion of query performance on a Plexara session.