Data Collection

Data Engineering

Trino Metadata Inspection and Query Analysis

Inspect Trino catalog, schema, and table structures via MCP tools, and analyze SQL execution plans and query run status, so data engineers can stop writing SQL blind.

IndustriesAll industries

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Tracking schema

events · properties

event · payment3 props

user_idstring

pay_amountnumber

channelstring

Analysis readyevidence attached

The Trino Metadata Inspection and Query Analysis Skill is a data-engineering capability in ThinkingAI's industry Skill library. It helps data engineers inspect the catalog, schema, and table structure of Trino data sources via MCP tools, analyze SQL execution plans (EXPLAIN / EXPLAIN ANALYZE), and view historical query records and run status, upgrading from writing SQL blind to a data-driven approach of checking metadata, then the execution plan, then writing SQL. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

trino-metadata-query-analysis

I want to put together a project data-table inventory for a new colleague: which event tables and user tables are actually in the ta schema, how big each one is, how many partitions, honestly I can't list them all myself. Query it from the metadata for me, and don't touch the business data.

MCP list_catalogs / list_schemas to navigate the data sources

Located catalog hive → schema ta

Query information_schema.tables to inventory the event and user tables

Matched 4 tables: v_event_2 / v_user_2 / v_event_5 / v_user_5

Read the v_event_2$partitions partition metadata: count partitions and date coverage

get_table_schema to confirm key field types

$part_date / $part_event are partition keys, pay_amount is numeric

Summarize the table inventory, partition scale, and query caveats

The inventory is ready, reading only metadata the whole way and not scanning a single row of business data. There are 4 core tables under ta, and the main event table ta.v_event_2 has 14,560 partitions and about 1.8 TB: querying this table without a partition filter means a 1.8 TB full-table scan.

1. Metadata query SQL

sql

-- 1. Inventory the event and user tables under the ta schema
SELECT "table_name", "table_type"
FROM information_schema.tables
WHERE "table_schema" = 'ta'
  AND ("table_name" LIKE 'v_event_%' OR "table_name" LIKE 'v_user_%')
ORDER BY "table_name";

-- 2. Measure the main event table's partition scale (reads partition metadata only, no business-data scan)
SELECT
  COUNT(*)          AS partition_count,
  MIN("$part_date") AS earliest_date,
  MAX("$part_date") AS latest_date
FROM ta."v_event_2$partitions"

2. Table inventory and partition scale

Table	Purpose	Partitions	Data size	Latest partition
ta.v_event_2	Production event table	14,560	1.8 TB	2026-07-16
ta.v_user_2	Production user table	Non-partitioned	4.2 GB	N/A
ta.v_event_5	Test event table	1,236	96 GB	2026-07-16
ta.v_user_5	Test user table	Non-partitioned	310 MB	N/A

← Scroll to see more

v_event_2's 14,560 partitions are 728 date partitions × 20 event partitions, with dates covering 2024-07-19 to 2026-07-16. Two key points for the new colleague: (1) the partition keys are $part_date + $part_event, and any query must put both in the WHERE clause; (2) pay_amount is a numeric type, don't compare it as a string: the project has a history of amount-stat deviations caused by treating it as a string.

Recommendation

Add this inventory to the new-hire onboarding doc, along with a fixed pre-SQL routine: check the metadata first (table schema → partition keys → field types), then use EXPLAIN to see the execution plan, and only then write the query. Debugging SQL written on guesswork starts at 2–3 hours; checking the metadata once takes 1 minute.

All operations in this run were read-only checks; nothing was created or modified.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

When data engineers write SQL in a Trino environment, about 70% of errors come from writing without understanding the data structure, not knowing which columns a table has, the column data types, or the partition fields. SQL written on guesswork throws errors that require repeated debugging, and a complex SQL query takes 2-3 hours on average to debug. A subtler problem is the lack of execution-plan analysis skills: the root cause of a slow query is plain to see in the EXPLAIN output, but most engineers cannot read it and are left with blind trial and error.

What it does

Metadata navigation: inspect the data structure layer by layer from catalog to schema to table to column, confirming field names and data types before writing SQL

Execution-plan analysis: supports EXPLAIN (static plan) and EXPLAIN ANALYZE (measured run), with output in TEXT/JSON/GRAPHVIZ formats

Query-record inspection: view the run status, resource consumption, and queue info of historical queries, and track submitted tasks

Strict read-only boundary: all operations are inspection and viewing only, never modifying data or creating tables, safe and reliable

When to use it

Confirming table structure, field names, data types, and partition fields before writing SQL

Analyzing bottleneck nodes of a slow query via its execution plan

Viewing the run status and resource consumption of an already-submitted query

Navigating to discover Trino catalog/schema names when you are unsure of them

Comparing the execution-plan differences of different SQL rewrites before tuning

In the field

Case

A data engineer · Trino table-structure confirmation and execution-plan analysis

The engineer was unsure of the event table's partition fields and column names. The Skill first navigated the data source with list_catalogs and list_schemas, then confirmed with get_table_schema that $part_date and $part_event are partition fields and pay_amount is a numeric type. After writing the SQL, explain_query revealed the Sort node accounted for 80% of the cost; after rewriting to add a LIMIT and partition filters, query time dropped from 45 minutes to 12 seconds.

FAQ

Can this Skill modify data?

No. All operations are read-only inspection: viewing metadata, analyzing execution plans, and viewing query status, never modifying any data or creating any objects.

What is the difference between EXPLAIN and EXPLAIN ANALYZE?

EXPLAIN generates a static plan as text without executing the query; EXPLAIN ANALYZE actually executes the query and returns measured runtime data.

What is the difference from the AE SQL Performance Optimization Skill?

Trino metadata inspection focuses on preventive checks, inspecting structure before writing SQL, while SQL Performance Optimization focuses on rewriting existing slow queries. The two are complementary.