chore: add some raw docs to inspect commands · adrientiburce/cli@ad6d03a · GitHub
Skip to content

Commit ad6d03a

Browse files
loongsweatybridge
authored andcommitted
chore: add some raw docs to inspect commands
1 parent eeef1dc commit ad6d03a

20 files changed

Lines changed: 197 additions & 7 deletions

‎docs/supabase/inspect/bloat.md‎

Lines changed: 7 additions & 7 deletions

‎docs/supabase/inspect/blocking.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
## blocking
2+
3+
This command displays statements that are currently holding locks that other statements are waiting to be released. This can be used in conjunction with `pg:locks` to determine which statements need to be terminated in order to resolve lock contention.
4+
5+
```
6+
blocked_pid │ blocking_statement │ blocking_duration │ blocking_pid │ blocked_statement │ blocked_duration
7+
─────────────┼──────────────────────────┼───────────────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────────┼──────────────────
8+
461 │ select count(*) from app │ 00:00:03.838314 │ 15682 │ UPDATE "app" SET "updated_at" = '2013─03─04 15:07:04.746688' WHERE "id" = 12823149 │ 00:00:03.821826
9+
```

‎docs/supabase/inspect/cache-hit.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
# cache-hit
2+
3+
This command provides information on the efficiency of the buffer cache, for both index reads (`index hit rate`) as well as table reads (`table hit rate`). A low buffer cache hit ratio can be a sign that the Heroku Postgres plan is too small for the workload.
4+
5+
6+
```
7+
name | ratio
8+
----------------+------------------------
9+
index hit rate | 0.99957765013541945832
10+
table hit rate | 1.00
11+
```

‎docs/supabase/inspect/calls.md‎

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
# calls
2+
3+
This command is much like [outliers](./outliers.md), but ordered by the number of times a statement has been called.
4+
5+
```
6+
Query | TOTAL EXECUTION TIME | PROPORTION OF TOTAL EXEC TIME | NUMBER CALLS | SYNC IO TIME
7+
-----------------------------------------+------------------+----------------+-------------+--------------
8+
SELECT * FROM usage_events WHERE (alp.. | 01:18:11.073333 | 0.6% | 102,120,780 | 00:00:00
9+
BEGIN | 00:00:51.285988 | 0.0% | 47,288,662 | 00:00:00
10+
COMMIT | 00:00:52.31724 | 0.0% | 47,288,615 | 00:00:00
11+
SELECT * FROM archivable_usage_event.. | 154:39:26.431466 | 72.2% | 34,211,877 | 00:00:00
12+
UPDATE usage_events SET reporter_id =.. | 00:52:35.986167 | 0.4% | 23,788,388 | 00:00:00
13+
INSERT INTO usage_events (id, retaine.. | 00:49:25.260245 | 0.4% | 21,990,326 | 00:00:00
14+
INSERT INTO usage_events (id, retaine.. | 01:42:59.436532 | 0.8% | 12,328,187 | 00:00:00
15+
SELECT * FROM app_ownership_events .. | 00:19:06.289521 | 0.1% | 744,976 | 00:00:00
16+
INSERT INTO app_ownership_events(id, .. | 00:26:59.885631 | 0.2% | 383,153 | 00:00:00
17+
UPDATE app_ownership_events SET app_i.. | 00:01:22.282337 | 0.0% | 359,741 | 00:00:00
18+
```
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# index-sizes
2+
3+
This command displays the size of each each index in the database. It is calculated by taking the number of pages (reported in `relpages`) and multiplying it by the page size (8192 bytes).
4+
5+
```
6+
NAME │ SIZE
7+
──────────────────────────────┼─────────────
8+
job_run_details_pkey │ 3856 kB
9+
schema_migrations_pkey │ 16 kB
10+
refresh_tokens_token_unique │ 8192 bytes
11+
users_instance_id_idx │ 0 bytes
12+
buckets_pkey │ 0 bytes
13+
```
Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
# index-usage
2+
3+
This command provides information on the efficiency of indexes, represented as what percentage of total scans were index scans. A low percentage can indicate under indexing, or wrong data being indexed.
4+
5+
```
6+
TABLE NAME │ PERCENTAGE OF TIMES INDEX USED │ ROWS IN TABLE
7+
────────────────────┼────────────────────────────────┼────────────────
8+
unindexed_table │ 0 │ 322911
9+
job │ 100 │ 1
10+
schema_migrations │ 97 │ 0
11+
migrations │ Insufficient data │ 0
12+
```

‎docs/supabase/inspect/locks.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
# locks
2+
3+
This command displays queries that have taken out an exlusive lock on a relation. Exclusive locks typically prevent other operations on that relation from taking place, and can be a cause of "hung" queries that are waiting for a lock to be granted.
4+
5+
```
6+
PID │ RELNAME │ TRANSACTION ID │ GRANTED │ QUERY │ AGE
7+
─────────┼─────────┼────────────────┼─────────┼─────────────────────────────────────────┼───────────
8+
328112 │ null │ 0 │ t │ SELECT * FROM logs; │ 00:04:20
9+
```
Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
# long-running-queries
2+
3+
This command displays currently running queries, that have been running for longer than 5 minutes, descending by duration. Very long running queries can be a source of multiple issues, such as preventing DDL statements completing or vacuum being unable to update `relfrozenxid`.
4+
5+
```
6+
PID │ DURATION │ QUERY
7+
───────┼─────────────────┼───────────────────────────────────────────────────────────────────────────────────────
8+
19578 | 02:29:11.200129 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1450645 LIMIT 1
9+
19465 | 02:26:05.542653 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1889881 LIMIT 1
10+
19632 | 02:24:46.962818 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1581884 LIMIT 1
11+
```

‎docs/supabase/inspect/outliers.md‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
# outliers
2+
3+
This command displays statements, obtained from `pg_stat_statements`, ordered by the amount of time to execute in aggregate. This includes the statement itself, the total execution time for that statement, the proportion of total execution time for all statements that statement has taken up, the number of times that statement has been called, and the amount of time that statement spent on synchronous I/O (reading/writing from the filesystem).
4+
5+
Typically, an efficient query will have an appropriate ratio of calls to total execution time, with as little time spent on I/O as possible. Queries that have a high total execution time but low call count should be investigated to improve their performance. Queries that have a high proportion of execution time being spent on synchronous I/O should also be investigated.
6+
7+
```
8+
9+
QUERY │ EXECUTION TIME │ PROPORTION OF EXEC TIME │ NUMBER CALLS │ SYNC IO TIME
10+
─────────────────────────────────────────┼──────────────────┼─────────────────────────┼──────────────┼───────────────
11+
SELECT * FROM archivable_usage_events.. | 154:39:26.431466 | 72.2% | 34,211,877 | 00:00:00
12+
COPY public.archivable_usage_events (.. | 50:38:33.198418 | 23.6% | 13 | 13:34:21.00108
13+
COPY public.usage_events (id, reporte.. | 02:32:16.335233 | 1.2% | 13 | 00:34:19.784318
14+
INSERT INTO usage_events (id, retaine.. | 01:42:59.436532 | 0.8% | 12,328,187 | 00:00:00
15+
SELECT * FROM usage_events WHERE (alp.. | 01:18:10.754354 | 0.6% | 102,114,301 | 00:00:00
16+
```
Lines changed: 1 addition & 0 deletions

0 commit comments

Comments
 (0)