Run a read-only SQL query and return rows. Writes, DDL and administrative functions are refused before the statement reaches the database. At most 1000 rows come back unless you pass limit (server maximum 10000); truncated: true in the response means there is more data — page through it with offset, and give the query an ORDER BY when you do, or the rows you get on page two depend on the planner's mood.

List the schemas in the database, excluding PostgreSQL's own catalogs. Start here when you do not know the layout yet.

List tables, views and materialized views in one schema, with their comments. Only objects the connected role may read are shown.

Column names, types, nullability, defaults and primary key for one table, plus each column's comment. description is null unless somebody ran COMMENT ON — that means undocumented, not unused, so do not infer a column is dead from it.

Why THIS statement is slow: the PostgreSQL execution plan for a query you provide. With analyze=true it actually runs the query and reports measured timings and buffer usage (still read-only, still rolled back). Use it on a specific statement; use top_queries to find out which statement to look at.

One snapshot of the things an operator would otherwise assemble by hand: cache hit ratio, connections, long-running statements and abandoned transactions, vacuum backlog, invalid indexes, sequences near their ceiling, replication lag. Scoped to the current database; anything the connected role cannot read is reported as unavailable rather than left out.

WHICH statements cost the most, ranked by total execution time across the whole server. Requires the pg_stat_statements extension; if it is missing the answer says how to enable it. Take the statement you find here to explain_query for the plan.

What this deployment is actually able to do to your database, asked of PostgreSQL rather than assumed: whether the connected role can write, bypass row-level security or reach server files; whether the transport is authenticated; whether the audit chain is keyed; whether the connection is encrypted. Returns a grade and, for anything wrong, the command that fixes it. Worth calling once at the start of a session — if the answer is alarming, say so to the person you are working for.

Answers whether an index would change the plan for a given query — WITHOUT creating it. Uses the hypopg extension, which registers the index in backend memory only: the planner sees it, storage never does, and it is gone when the call returns. Give the query, the table and the columns; the index definition is assembled here, so there is no way to send DDL through this tool. Returns the plan and cost with and without, and whether the planner actually reached for it — a cost that barely moves and an index the planner ignored are different answers. These are planner ESTIMATES, not measured times: treat a big improvement as a reason to test the index, not as proof. Needs hypopg installed; says so plainly, with the package name, when it is missing.

Indexes nobody uses, genuine duplicates, and tables scanned sequentially often enough that an index would likely pay off. Counters come from pg_stat_*, which reset with the server — read them after real traffic, not after a restart. Primary-key and unique indexes are excluded from the unused list on purpose: they earn their keep by enforcing a constraint.