Catalog

The objects most table-first tools forget. Five panels with one-click ops on each.

#The five panels

Panel	Source	One-click ops
Views	`pg_views` + materialized view extras from `pg_matviews`.	Refresh (matview), drop, edit definition.
Sequences	`pg_sequences`.	Read current value, alter increment/start, restart at value, drop.
Triggers	`pg_trigger` joined with `pg_proc` for the function body.	Disable, enable, drop. The function body is shown read-only — edits go via Migrate.
Functions	`pg_proc` filtered to user schemas.	Read body, see callers, drop. Editing the body lives in Migrate.
Indexes	`pg_indexes` joined with `pg_stat_user_indexes` for usage stats.	REINDEX (CONCURRENTLY when supported), drop, mark unused.

#Index usage

The Indexes panel sorts by usage statistics from pg_stat_user_indexes— index scans, tuples fetched. Indexes with zero scans since the last reset are flagged. They're prime candidates for expand-contract drops on the next maintenance window.

SQL

8 lines


1-- Same query Studio uses to flag unused indexes:
2SELECT
3  schemaname, tablename, indexname,
4  idx_scan, idx_tup_read, idx_tup_fetch,
5  pg_size_pretty(pg_relation_size(indexrelid)) AS size
6FROM pg_stat_user_indexes
7WHERE idx_scan = 0
8ORDER BY pg_relation_size(indexrelid) DESC;

#Triggers and functions

Editing a trigger or function body from Studio is intentionally disabled — those belong in version-controlled migrations. Studio shows the body read-only with a "create migration from this" button that scaffolds a Migrate file with the current body as the starting point.

#Materialized views

Each row has a refresh button. REFRESH MATERIALIZED VIEW CONCURRENTLY when the matview has a unique index, plain REFRESH otherwise. Studio shows the difference inline so you know which one will block readers.