This is a preview feature only available on Business plans. Note that preview features may be operationally incomplete and may offer limited backward compatibility. This feature is only available for organization admins.
RECENT_QUERIES view
The MD_INFORMATION_SCHEMA.RECENT_QUERIES view provides organization admins with a consolidated view of all currently running or recently completed queries across their full organization. It complements the MD_INFORMATION_SCHEMA.QUERY_HISTORY view, which is geared towards analytics of past events and has some delays, with a more realtime view of recent queries (active and completed) that are not yet exposed in QUERY_HISTORY.
Schema​
When you query the MD_INFORMATION_SCHEMA.RECENT_QUERIES view, the query results contain one row for each query that is running or has recently completed in the organization. Note that the information in this view is updated every couple of seconds.
The MD_INFORMATION_SCHEMA.RECENT_QUERIES view shares the same schema as the MD_INFORMATION_SCHEMA.QUERY_HISTORY view. The main difference is that for queries that have not completed yet the END_TIME field is null, and all other fields represent ongoing metrics that will be updated every few seconds.
Full schema:
| Column Name | Data Type | Value |
|---|---|---|
| QUERY_ID | UUID | A unique ID representing the particular query run |
| QUERY_TEXT | STRING | Query SQL text (up to 100k chars) |
| START_TIME | TIMESTAMPTZ | Start time of the query |
| END_TIME | TIMESTAMPTZ | End time of the query, if the query is completed |
| EXECUTION_TIME | INTERVAL | Duration where the query is actively executing |
| WAIT_TIME | INTERVAL | Duration where the query is waiting on resources to become available. For example a query needs to wait because other queries are using all available execution threads, or a query might be waiting on data to become available (in case of data upload). |
| TOTAL_ELAPSED_TIME | INTERVAL | Total duration of the query |
| ERROR_MESSAGE | STRING | Error message, if the query returned an error |
| ERROR_TYPE | STRING | Error type, if the query returned an error |
| USER_AGENT | STRING | User agent of the client |
| USER_NAME | STRING | Identifier for the MotherDuck user in their organization |
| QUERY_NR | UBIGINT | ID of the query within the transaction that ran the query. Number that just increments for each query that is run within a given transaction |
| TRANSACTION_NR | UBIGINT | ID of the transaction that contained the query. Number that just increments for each new transaction on a given connection |
| CONNECTION_ID | UUID | Unique ID for the client DuckDB connection where the query was issued |
| DUCKDB_ID | UUID | Unique ID for the client DuckDB instance where the query was issued |
| DUCKDB_VERSION | STRING | Client DuckDB version that issued the query |
| INSTANCE_TYPE | STRING | The type of duckling that the query was run on (Pulse / Standard / Jumbo / Mega / Giga / ...) |
| QUERY_TYPE | STRING | The nature of the query (DDL / DML / QUERY / ...) |
| BYTES_UPLOADED | UBIGINT | Number of bytes uploaded from client to server (relevant for hybrid queries) |
| BYTES_DOWNLOADED | UBIGINT | Number of bytes downloaded from server to client (relevant for hybrid queries) |
| BYTES_SPILLED_TO_DISK | UBIGINT | Total number of bytes spilled to disk for "larger than in-memory" workloads |
Note that the fields START_TIME, END_TIME, TOTAL_ELAPSED_TIME, ERROR_MESSAGE, and ERROR_TYPE are currently just captured on the server (i.e. when query starts and ends on server), in the future they will be based on client information too (taking better into account the full hybrid context).
Example usage​
from MD_INFORMATION_SCHEMA.RECENT_QUERIES where end_time is null limit 10;
Limitations​
The RECENT_QUERIES view has been optimized for quickly answering questions such as "Which ongoing queries in my organization are taking a long time to complete". Query results of this view are therefore limited to 1000 rows, but support filter pushdowns so that this limit only applies after some basic filters. Take for example the following query:
from MD_INFORMATION_SCHEMA.RECENT_QUERIES where USER_NAME = 'my_name';
The 1000 row limit only applies after the USER_NAME has been applied. To check what filters are pushed down and apply before the row limit, the "filters" section of the MD_SERVER_RECENT_QUERIES table scan operator can be checked in the query plan explain output.