Release v0.8.0 · ortic/pythia

Highlights

The real plan at the breakpoint. When the debugger stops, a new SQL panel lists the statements your code ran, each linked to its line, with the plan's estimated and actual rows side by side and misestimates flagged. Ask AI analyzes it with the code around it and the variables at the stop (#152).
Plans with actual rows everywhere. Run with statistics and the monitor's session and SQL details show the plan as a tree with Starts, E-Rows, A-Rows, A-Time and Buffers, and name the worst misestimate (#152).
Maintenance window and maintenance scan for Oracle, PostgreSQL, MySQL/MariaDB and SQL Server. They show what a table needs (stale statistics, unusable indexes, dead rows, fragmentation) and the statements that fix it (#144, #145).
Users and roles on MySQL/MariaDB, PostgreSQL and SQL Server. You can create and edit them in a form that shows the statements before it runs them (#142).
The single record view edits, and result grids keep the keyboard after a click (#141, #143).

The SQL panel beside the variables lists the statements the debugged session ran from PL/SQL since the start. Each has the unit and line it came from (V$SQL.PROGRAM_ID / PROGRAM_LINE#), anonymous blocks and dynamic SQL included, and the line link opens it.
At every stop it selects the statement at the stopped line, or the closest one before it. It shows that statement's plan with the last execution's Starts, E-Rows, A-Rows, A-Time and Buffers next to the estimates.
Misestimates: A-Rows is compared with E-Rows × Starts, which is right under nested loops. Lines off by 10× or more are marked, and the deepest one is named above the plan, e.g. "estimated 25,000 rows, got 200 (125× fewer)".
It says what the figures are: when a statement is still running (stopped inside its loop), it shows the last finished execution's figures, or says they come when the cursor is closed. It also says when other sessions run the statement with another plan.
Ask AI sends the plan with the statistics, the code around the line and the variables at the stop (as bind values, under the data policy). Copy plan copies DBMS_XPLAN's report.
Plan statistics in the debugger toolbar, on by default, runs the debugged session with STATISTICS_LEVEL = ALL. That gives its statements child cursors of their own.
Needs SELECT_CATALOG_ROLE, or SELECT on V$OPEN_CURSOR, V$SQL and V$SQL_PLAN_STATISTICS_ALL.

Maintenance… on a table, materialized view or index opens a window with its state first, as evidence for what it needs. Then come the database's tasks, each with its options and what it locks or commits:
- Oracle: gather, delete, lock or unlock statistics; rebuild unusable indexes and (sub)partitions, or an index; shrink space; move (online from 12.2).
- PostgreSQL: VACUUM (analyze, freeze, full, verbose), ANALYZE, REINDEX (concurrently from 12).
- MySQL: ANALYZE, OPTIMIZE and CHECK TABLE, with their answers.
- SQL Server: UPDATE STATISTICS (sampled or full scan); rebuild (online on Enterprise) or reorganize the indexes.
A maintenance scan of a schema (Oracle, MySQL) or database (PostgreSQL, SQL Server) lists what its tables need. Each finding comes with its evidence and the statements that fix it, and the picked ones run as a batch (Tools → Maintenance Scan, or Maintenance scan… on the Tables folder).
The statements show before they run, one by one, on the window's own session with Break. While a statement runs, the window shows the progress the database reports. On a production connection it asks first; on a read-only one it doesn't run.
The dashboards' findings offer their fix: PostgreSQL's table with many dead rows opens its maintenance on VACUUM (ANALYZE), and transaction ID wraparound opens the scan. MySQL's dashboard names the table with the most reclaimable space, with OPTIMIZE TABLE.

Users and roles can be created and edited (#142), like Oracle's. New user… / New role… on the Users and Roles sections (and in File → New Object), and Edit user… on one, open a form that shows the statements before Apply:
- MySQL/MariaDB: user and host, password, expired, locked; granted roles and privileges on the server, a database or a table.
- PostgreSQL: password, valid until, connection limit and role options; memberships; privileges on databases, schemas, tables and sequences.
- SQL Server: users for a login, without login or with a password (contained databases); default schema; role memberships; permissions granted, grantable or denied.

Plans with actual rows: Run with statistics and the monitor's session and SQL details show the actual plan as a tree with Starts, E-Rows, A-Rows, A-Time, Buffers and Reads, the worst misestimate named above it, and DBMS_XPLAN's report a click away (#152).
Session details: the plan has the last execution's statistics (ALLSTATS LAST) when the cursor collected them.
AI assistant: the plan it gets for a cursor includes the last execution's statistics too.

Result grids lost the keys one frame after a click: the arrows, Enter/F2, typing, Delete and Ctrl+C/V did nothing unless pressed right away (#143).
The single record view couldn't edit (#141). Its fields now edit like the grid's cells, and pending edits, inserted rows and the row filter are respected.
SQL Server: UPDATE STATISTICS in a SQL window without auto-commit left a transaction open (#150).
MySQL/MariaDB, PostgreSQL and SQL Server: New user… opened a form that only said the tool isn't available (#142).
MariaDB:
- session details failed on the plan (before 10.9), or held up the monitor for 30 s for a session waiting for a row lock (#146);
- session details showed no row locks or blocker (#147);
- the dashboard showed no replica connections (#148), and its lock waits named tables with backticks (#149).

Full Changelog: v0.7.0...v0.8.0