Product terms
- Project
- A workspace that links database connections and optional source code to one analysis schedule, activity thread, and set of auto-mode permissions.
- Host
- A machine used by a connection: either one running the dbtempo CLI daemon or an SSH bastion used by a managed connection. A host is not the database itself.
- Connection
- A saved logical database target with its engine, endpoint, database or schema scope, credentials, and direct, SSH, or CLI transport.
- Thread
- The conversation and activity record that holds submitted artifacts, analysis progress, results, and context requests. Project runs can create or update a linked thread.
- Query digest
- A stable identity derived from normalized SQL. It groups equivalent query shapes whose literal values differ and links workload observations to recommendations and source locations.
- Readiness
- The current per-connection result of connectivity, schema-access, and query-source checks. Required failures block analysis; recommended or optional failures reduce coverage.
- Recommendation
- A durable finding with a diagnosis, confidence, evidence, proposed fix, status, and any available risk, rollback, source, or plan context.
- Managed collection
- A scan dbtempo runs over a direct or SSH database connection. The managed runner performs the collection without a customer-hosted CLI daemon.
- Source analysis
- Use of an indexed GitHub repository or host path to find the code that builds a query, adding call-site evidence to a recommendation and, where a fix is in code, a proposed code change.
Database performance terms
- Rows examined
- How many rows the database read to answer a query, as opposed to how many it returned. A query that examines a million rows to return ten is doing work an index could skip; MySQL reports it per statement in performance_schema and the slow query log.
- Full table scan
- A plan that reads every row of a table because no index fits the filter. MySQL shows it as type ALL in EXPLAIN; PostgreSQL shows a Seq Scan. On a small table it is fine; on a growing one its cost grows with the table.
- Filesort
- MySQL sorting rows after reading them because no index returns them in the requested ORDER BY order. EXPLAIN shows "Using filesort". An index whose columns match the filter and then the sort order can remove it.
- Covering index
- An index that contains every column a query reads, so the database answers from the index alone without visiting the table rows. MySQL marks it "Using index"; PostgreSQL shows an Index Only Scan.
- Composite index
- An index on several columns in a fixed order. It serves filters on a leading prefix of those columns: an index on (customer_id, created_at) helps WHERE customer_id = ?, but not WHERE created_at > ? alone.
- Redundant index
- An index another index already covers, such as (email) next to (email, created_at). It costs writes and memory while serving nothing the wider one does not. dbtempo suggests dropping it only when it is not unique.
- Unused index
- An index no query has read since the statistics were last reset, which on PostgreSQL is an idx_scan of zero in pg_stat_user_indexes. Every write still maintains it.
- EXPLAIN plan
- The database’s description of how it will run a query: which indexes it uses, the join order, and the estimated rows at each step. By default dbtempo reads plans without running the statement. On PostgreSQL it uses EXPLAIN ANALYZE, which does run it, only after a project owner turns on query execution for that project.
- performance_schema
- MySQL and MariaDB’s built-in instrumentation. Its statement digest tables keep per-query-shape counts, total time and rows examined, which is where dbtempo reads MySQL workload from.
- pg_stat_statements
- A PostgreSQL extension that records execution statistics per normalized query: calls, total and mean time, rows and buffer use. It has to be listed in shared_preload_libraries, which needs a server restart.
- Slow query log
- A MySQL and MariaDB log of statements that ran longer than long_query_time, with their duration and rows examined. dbtempo can read it over SSH or take it as an upload.
- HypoPG
- A PostgreSQL extension that creates hypothetical indexes: the planner can use them in EXPLAIN, but nothing is built on disk. dbtempo uses it to check that the planner would pick a proposed index before recommending it.
- N+1 query
- One query that loads a list, followed by one more query per item in that list, usually from an ORM loading a relation lazily inside a loop. Ten items cost eleven round trips; a thousand cost a thousand and one. A join or a single batched IN query replaces them.
- Transaction ID wraparound
- PostgreSQL numbers transactions with a 32-bit counter. If vacuum does not freeze old rows before the counter nears its limit, the server stops accepting writes to protect data, so the age of the oldest unfrozen transaction is worth watching.
- Stale statistics
- Planner statistics that no longer describe the table because many rows changed since the last ANALYZE. The planner then misjudges row counts and can pick a bad plan for a query nobody changed.