QUERY_HISTORY view
Marked preset roles include the permission by default; a custom role qualifies when it inherits a role that includes it.
The Duckling overview page (Settings → Duckling overview) gives a 24-hour summary of activity across every Duckling in the organization and requires the separate View Duckling overview permission. See Duckling overview for details.
You can monitor and cancel running queries in the MotherDuck UI under Settings → Running Queries. See Running Queries for details.
The MD_INFORMATION_SCHEMA.QUERY_HISTORY view provides a consolidated view of all queries run across an organization.
Query history is retained indefinitely. This retention policy may change in the future. If you depend on long-term query history, we recommend periodically exporting it to your own storage.
Schema​
When you query the MD_INFORMATION_SCHEMA.QUERY_HISTORY view, the query results contain one row for each query that was run in the organization. Note that the information in this view will have some delays. A more realtime view of ongoing and completed queries that have not been captured in QUERY_HISTORY yet is provided through the MD_INFORMATION_SCHEMA.RECENT_QUERIES view.
The MD_INFORMATION_SCHEMA.QUERY_HISTORY view has the following schema:
| Column Name | Data Type | Value |
|---|---|---|
| QUERY_ID | UUID | A unique ID representing the particular query run. You can retrieve this value on the client with MD_LAST_QUERY_ID(). |
| 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 |
| 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 may need to wait because other queries are using all available execution threads. Alternatively, a query may be waiting on data to become available (in case of data upload). Wait time is a useful signal for query optimization or uncovering workloads that could benefit from scaling compute horizontally with more ducklings or vertically with larger ducklings. |
| 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 size 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 |
| DUCKLING_ID | STRING | Identifies the duckling that ran the query. It is composed of the user name and a qualifier (rw for read-write ducklings, or rs.0, rs.1, ... for the respective read scaling duckling) |
| SESSION_NAME | STRING | The session_name that was supplied when connecting to MotherDuck |
The fields START_TIME, END_TIME, TOTAL_ELAPSED_TIME, ERROR_MESSAGE, and ERROR_TYPE are captured on the server (that is, 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.QUERY_HISTORY limit 10;