pg-extras 0.4.0

PostgreSQL performance database insights
Documentation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
# rust-pg-extras [![Latest Version]https://img.shields.io/crates/v/pg-extras.svg]https://crates.io/crates/pg-extras [![GH Actions]https://github.com/pawurb/rust-pg-extras/actions/workflows/ci.yml/badge.svg]https://github.com/pawurb/rust-pg-extras/actions

Rust port of [Heroku PG Extras](https://github.com/heroku/heroku-pg-extras) with several additions and improvements. The goal of this project is to provide powerful insights into the PostgreSQL database for Rust apps that are not using the Heroku PostgreSQL plugin.

Queries can be used to obtain information about a Postgres instance, that may be useful when analyzing performance issues. This includes information about locks, index usage, buffer cache hit ratios and vacuum statistics. Rust API enables developers to easily integrate the tool into e.g. automatic monitoring tasks.

You can check out this blog post for detailed step by step tutorial on how to [optimize PostgreSQL using PG Extras library](https://pawelurbanek.com/postgresql-fix-performance).

Alternative versions:

- [Ruby on Rails]https://github.com/pawurb/rails-pg-extras

- [NodeJS]https://github.com/pawurb/node-postgres-extras

- [Elixir]https://github.com/pawurb/ecto_psql_extras

- [Python]https://github.com/pawurb/python-pg-extras

- [Haskell]https://github.com/pawurb/haskell-pg-extras

## Installation

In your Cargo.toml

```rust
pg-extras = "0.3"
```

`calls` and `outliers` queries require [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) extension.

You can check if it is enabled in your database by running:

```rust
use pg_extras::{render_table, extensions}

render_table(extensions()?);
```

You should see the similar line in the output:

```bash
| pg_stat_statements  | 1.7  | 1.7 | track execution statistics of all SQL statements executed |
```

`ssl_used` requires `sslinfo` extension, and `buffercache_usage`/`buffercache_usage` queries need `pg_buffercache`. You can enable them all by running this SQL:

```sql
CREATE EXTENSION IF NOT EXISTS sslinfo;
CREATE EXTENSION IF NOT EXISTS pg_buffercache;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
```

## Usage

Package expects the `ENV['PG_EXTRAS_DATABASE_URL']` or `ENV['DATABASE_URL']` value in the following format:

```rust
ENV["DATABASE_URL"] = "postgresql://postgres:secret@localhost:5432/database_name"
```

You can run queries using a Rust API to display an ASCCI table with results:

```rust
use pg_extras::{render_table, cache_hit}

render_table(cache_hit(None).await?);

```
```bash
+----------------+------------------------+
|        Index and table hit rate         |
+----------------+------------------------+
| name           | ratio                  |
+----------------+------------------------+
| index hit rate | 0.97796610169491525424 |
| table hit rate | 0.96724294813466787989 |
+----------------+------------------------+
```

Alternatively you can work directly with returned structs:

```rust
use pg_extras::{render_table, cache_hit, CacheHit}

let cache_hit_res: Vec<CacheHit> = cache_hit(None).await?;
println!("{:?}", cache_hit_res);

// [CacheHit { name: "index hit rate", ratio:  0.9779... }, CacheHit { name: "table hit rate", ratio: 0.9672... }]

```

Some methods accept params allowing you to customize queries:

```rust
cache_hit(Some("other_schema".to_string)).await?;
```

You can customize the default `public` schema by setting `ENV['PG_EXTRAS_SCHEMA']` value.

## Command line

After running `cargo install pg-extras` you can use `pg_extras` shell command:

```bash
$ pg_extras cache_hit
+----------------+------------------------+
| /* Index and table hit rate */          |
+================+========================+
| name           | ratio                  |
+----------------+------------------------+
| index hit rate | 0.99138647287107053837 |
+----------------+------------------------+
| table hit rate | 0.99984856854492081787 |
+----------------+------------------------+
``````

## Available methods

### `cache_hit`

```rust
struct CacheHit {
    name: String,
    ratio: Decimal,
}

cache_hit(schema: Option<String>) -> Result<Vec<CacheHit>, PgExtrasError>

      name      |         ratio
----------------+------------------------
 index hit rate | 0.99957765013541945832
 table hit rate |                   1.00
(2 rows)
```

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 Postgres instance is too small for the workload.

[More info](https://pawelurbanek.com/postgresql-fix-performance#cache-hit)

### `index_cache_hit`

```rust
struct IndexCacheHit {
    name: String,
    buffer_hits: i64,
    block_reads: i64,
    total_read: i64,
    ratio: String,
}

index_cache_hit(schema: Option<String>) -> Result<Vec<IndexCacheHit>, PgExtrasError>

| name                  | buffer_hits | block_reads | total_read | ratio             |
+-----------------------+-------------+-------------+------------+-------------------+
| teams                 | 187665      | 109         | 187774     | 0.999419514948821 |
| subscriptions         | 5160        | 6           | 5166       | 0.99883855981417  |
| plans                 | 5718        | 9           | 5727       | 0.998428496595076 |
(truncated results for brevity)
```

The same as `cache_hit` with each table's indexes cache hit info displayed separately.

[More info](https://pawelurbanek.com/postgresql-fix-performance#cache-hit)

### `table_cache_hit`

```rust
struct TableCacheHit {
    name: String,
    buffer_hits: i64,
    block_reads: i64,
    total_read: i64,
    ratio: String,
}

table_cache_hit() -> Result<Vec<TableCacheHit>, PgExtrasError>

| name                  | buffer_hits | block_reads | total_read | ratio             |
+-----------------------+-------------+-------------+------------+-------------------+
| plans                 | 32123       | 2           | 32125      | 0.999937743190662 |
| subscriptions         | 95021       | 8           | 95029      | 0.999915815172211 |
| teams                 | 171637      | 200         | 171837     | 0.99883610631005  |
(truncated results for brevity)
```

The same as `cache_hit` with each table's cache hit info displayed seperately.

[More info](https://pawelurbanek.com/postgresql-fix-performance#cache-hit)

### `db_settings`

```rust
struct DbSettings {
    name: String,
    setting: String,
    unit: String,
    short_desc: String,
}

db_settings() -> Result<Vec<DbSettings>, PgExtrasError>

             name             | setting | unit |
------------------------------+---------+------+
 checkpoint_completion_target | 0.7     |      |
 default_statistics_target    | 100     |      |
 effective_cache_size         | 1350000 | 8kB  |
 effective_io_concurrency     | 1       |      |
(truncated results for brevity)

```

This method displays values for selected PostgreSQL settings. You can compare them with settings recommended by [PGTune](https://pgtune.leopard.in.ua/#/) and tweak values to improve performance.

[More info](https://pawelurbanek.com/postgresql-fix-performance#cache-hit)

### `ssl_used`

```rust
struct SslUsed {
    ssl_used: bool,
}

ssl_used() -> Result<Vec<SslUsed>, PgExtrasError>

| ssl_is_used                     |
+---------------------------------+
| t                               |

```

Returns boolean indicating if an encrypted SSL is currently used. Connecting to the database via an unencrypted connection is a critical security risk.

### `index_usage`

```rust
struct IndexUsage {
    relname: String,
    percent_of_times_index_used: String,
    rows_in_table: i64,
}

index_usage(schema: Option<String>) -> Result<Vec<IndexUsage>, PgExtrasError>

       relname       | percent_of_times_index_used | rows_in_table
---------------------+-----------------------------+---------------
 events              |                          65 |       1217347
 app_infos           |                          74 |        314057
 app_infos_user_info |                           0 |        198848
 user_info           |                           5 |         94545
 delayed_jobs        |                          27 |             0
(5 rows)
```

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.

### `locks`

```rust
struct Locks {
    pid: i32,
    relname: String,
    transactionid: String,
    granted: bool,
    mode: String,
    query_snippet: String,
    age: String,
    application: String,
}

locks() -> Result<Vec<Locks>, PgExtrasError>

 procpid | relname | transactionid | granted |     query_snippet     | mode             |       age        |   application |
---------+---------+---------------+---------+-----------------------+------------------------------------------------------
   31776 |         |               | t       | <IDLE> in transaction | ExclusiveLock    |  00:19:29.837898 |  bin/rails
   31776 |         |          1294 | t       | <IDLE> in transaction | RowExclusiveLock |  00:19:29.837898 |  bin/rails
   31912 |         |               | t       | select * from hello;  | ExclusiveLock    |  00:19:17.94259  |  bin/rails
    3443 |         |               | t       |                      +| ExclusiveLock    |  00:00:00        |  bin/sidekiq
         |         |               |         |    select            +|                  |                  |
         |         |               |         |      pg_stat_activi   |                  |                  |
(4 rows)
```

This command displays queries that have taken out an exclusive 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.

[More info](https://pawelurbanek.com/postgresql-fix-performance#deadlocks)

### `all_locks`

```rust
struct AllLocks {
    pid: String,
    relname: String,
    transactionid: String,
    granted: String,
    mode: String,
    query_snippet: String,
    age: String,
    application: String,
}

all_locks() -> Result<Vec<AllLocks>, PgExtrasError> 

```

This command displays all the current locks, regardless of their type.

### `outliers`

```rust
struct Outliers {
    total_exec_time: PgInterval,
    prop_exec_time: String,
    ncalls: String,
    sync_io_time: PgInterval,
    query: String,
}

outliers() -> Result<Vec<Outliers>, PgExtrasError>

                   query                 |    exec_time     | prop_exec_time |   ncalls    | sync_io_time
-----------------------------------------+------------------+----------------+-------------+--------------
 SELECT * FROM archivable_usage_events.. | 154:39:26.431466 | 72.2%          | 34,211,877  | 00:00:00
 COPY public.archivable_usage_events (.. | 50:38:33.198418  | 23.6%          | 13          | 13:34:21.00108
 COPY public.usage_events (id, reporte.. | 02:32:16.335233  | 1.2%           | 13          | 00:34:19.784318
 INSERT INTO usage_events (id, retaine.. | 01:42:59.436532  | 0.8%           | 12,328,187  | 00:00:00
 SELECT * FROM usage_events WHERE (alp.. | 01:18:10.754354  | 0.6%           | 102,114,301 | 00:00:00
 UPDATE usage_events SET reporter_id =.. | 00:52:35.683254  | 0.4%           | 23,786,348  | 00:00:00
 INSERT INTO usage_events (id, retaine.. | 00:49:24.952561  | 0.4%           | 21,988,201  | 00:00:00
(truncated results for brevity)
```

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 file system).

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.

[More info](https://pawelurbanek.com/postgresql-fix-performance#missing-indexes)

### `calls`

```rust
struct Calls {
    qry: String,
    exec_time: PgInterval,
    prop_exec_time: String,
    ncalls: String,
    sync_io_time: PgInterval,
}

calls(limit: Option<String>) -> Result<Vec<Calls>, PgExtrasError>

                   qry                   |    exec_time     | prop_exec_time |   ncalls    | sync_io_time
-----------------------------------------+------------------+----------------+-------------+--------------
 SELECT * FROM usage_events WHERE (alp.. | 01:18:11.073333  | 0.6%           | 102,120,780 | 00:00:00
 BEGIN                                   | 00:00:51.285988  | 0.0%           | 47,288,662  | 00:00:00
 COMMIT                                  | 00:00:52.31724   | 0.0%           | 47,288,615  | 00:00:00
 SELECT * FROM  archivable_usage_event.. | 154:39:26.431466 | 72.2%          | 34,211,877  | 00:00:00
 UPDATE usage_events SET reporter_id =.. | 00:52:35.986167  | 0.4%           | 23,788,388  | 00:00:00
 INSERT INTO usage_events (id, retaine.. | 00:49:25.260245  | 0.4%           | 21,990,326  | 00:00:00
 INSERT INTO usage_events (id, retaine.. | 01:42:59.436532  | 0.8%           | 12,328,187  | 00:00:00
(truncated results for brevity)
```

This command is much like `pg:outliers`, but ordered by the number of times a statement has been called.

[More info](https://pawelurbanek.com/postgresql-fix-performance#missing-indexes)

### `blocking`

```rust
struct Blocking {
    blocked_pid: i32,
    blocking_statement: String,
    blocking_duration: PgInterval,
    blocking_pid: i32,
    blocked_statement: String,
    blocked_duration: PgInterval,
    blocked_sql_app: String,
    blocking_sql_app: String,
}

blocking(limit: Option<String>) -> Result<Vec<Blocking>, PgExtrasError>

 blocked_pid |    blocking_statement    | blocking_duration | blocking_pid |                                        blocked_statement                           | blocked_duration
-------------+--------------------------+-------------------+--------------+------------------------------------------------------------------------------------+------------------
         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
(1 row)
```

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.

[More info](https://pawelurbanek.com/postgresql-fix-performance#deadlocks)

### `total_index_size`

```rust
struct TotalIndexSize {
    size: String,
}

total_index_size() -> Result<Vec<TotalIndexSize>, PgExtrasError>

  size
-------
 28194 MB
(1 row)
```

This command displays the total size of all indexes on the database, in MB. It is calculated by taking the number of pages (reported in `relpages`) and multiplying it by the page size (8192 bytes).

### `index_size`

```rust
 struct IndexSize {
    name: String,
    size: String,
    schema: String,
}

index_size() -> Result<Vec<IndexSize>, PgExtrasError> 

                             name                              |  size   | schema |
---------------------------------------------------------------+-------------------
 idx_activity_attemptable_and_type_lesson_enrollment           | 5196 MB | public |
 index_enrollment_attemptables_by_attempt_and_last_in_group    | 4045 MB | public |
 index_attempts_on_student_id                                  | 2611 MB | custom |
 enrollment_activity_attemptables_pkey                         | 2513 MB | custom |
 index_attempts_on_student_id_final_attemptable_type           | 2466 MB | custom |
 attempts_pkey                                                 | 2466 MB | custom |
 index_attempts_on_response_id                                 | 2404 MB | public |
 index_attempts_on_enrollment_id                               | 1957 MB | public |
 index_enrollment_attemptables_by_enrollment_activity_id       | 1789 MB | public |
 enrollment_activities_pkey                                    |  458 MB | public |
(truncated results for brevity)
```

This command displays the size of each each index in the database, in MB. It is calculated by taking the number of pages (reported in `relpages`) and multiplying it by the page size (8192 bytes).

### `table_size`

```rust
struct TableSize {
    name: String,
    size: String,
    schema: String,
}

table_size() -> Result<Vec<TableSize>, PgExtrasError> 

                             name                              |  size   | schema |
---------------------------------------------------------------+-------------------
 learning_coaches                                              |  196 MB | public |
 states                                                        |  145 MB | public |
 grade_levels                                                  |  111 MB | custom |
 charities_customers                                           |   73 MB | public |
 charities                                                     |   66 MB | public |
(truncated results for brevity)
```

This command displays the size of each table and materialized view in the database, in MB. It is calculated by using the system administration function `pg_table_size()`, which includes the size of the main data fork, free space map, visibility map and TOAST data.

### `table_indexes_size`

```rust
TableIndexesSize {
    table: String,
    index_size: String,
}

table_indexes_size(schema: Option<String>) -> Result<Vec<TableIndexesSize>, PgExtrasError> 

                             table                             | indexes_size
---------------------------------------------------------------+--------------
 learning_coaches                                              |    153 MB
 states                                                        |    125 MB
 charities_customers                                           |     93 MB
 charities                                                     |     16 MB
 grade_levels                                                  |     11 MB
(truncated results for brevity)
```

This command displays the total size of indexes for each table and materialized view, in MB. It is calculated by using the system administration function `pg_indexes_size()`.

### `total_table_size`

```rust
struct TotalTableSize {
    name: String,
    size: String,
}

total_table_size() -> Result<Vec<TotalTableSize>, PgExtrasError>

                             name                              |  size
---------------------------------------------------------------+---------
 learning_coaches                                              |  349 MB
 states                                                        |  270 MB
 charities_customers                                           |  166 MB
 grade_levels                                                  |  122 MB
 charities                                                     |   82 MB
(truncated results for brevity)
```

This command displays the total size of each table and materialized view in the database, in MB. It is calculated by using the system administration function `pg_total_relation_size()`, which includes table size, total index size and TOAST data.

### `unused_indexes`

```rust
struct UnusedIndexes {
    table: String,
    index: String,
    index_size: String,
    index_scans: i64,
}

unused_indexes(schema: Option<String>) -> Result<Vec<UnusedIndexes>, PgExtrasError> 

          table      |                       index                | index_size | index_scans
---------------------+--------------------------------------------+------------+-------------
 public.grade_levels | index_placement_attempts_on_grade_level_id | 97 MB      |           0
 public.observations | observations_attrs_grade_resources         | 33 MB      |           0
 public.messages     | user_resource_id_idx                       | 12 MB      |           0
(3 rows)
```

This command displays indexes that have < 50 scans recorded against them, and are greater than 5 pages in size, ordered by size relative to the number of index scans. This command is generally useful for eliminating indexes that are unused, which can impact write performance, as well as read performance should they occupy space in memory.

[More info](https://pawelurbanek.com/postgresql-fix-performance#unused-indexes)

### `duplicate_indexes`

```rust
struct DuplicateIndexes {
    size: String,
    idx1: String,
    idx2: String,
    idx3: String,
    idx4: String,
}

duplicate_indexes() -> Result<Vec<DuplicateIndexes>, PgExtrasError> 

| size       |  idx1        |  idx2          |  idx3    |  idx4     |
+------------+--------------+----------------+----------+-----------+
| 128 k      | users_pkey   | index_users_id |          |           |
```

This command displays multiple indexes that have the same set of columns, same opclass, expression and predicate - which make them equivalent. Usually it's safe to drop one of them.

### `null_indexes`

```rust
struct NullIndexes {
    oid: String,
    index: String,
    index_size: String,
    unique: bool,
    indexed_column: String,
    table: String,
    null_frac: String,
    expected_saving: String,
    schema: String,
}

null_indexes(min_relation_size_mb: Option<String>) -> Result<Vec<NullIndexes>, PgExtrasError> 

   oid   |         index      | index_size | unique | indexed_column | null_frac | expected_saving
---------+--------------------+------------+--------+----------------+-----------+-----------------
  183764 | users_reset_token  | 1445 MB    | t      | reset_token    |   97.00%  | 1401 MB
   88732 | plan_cancelled_at  | 539 MB     | f      | cancelled_at   |    8.30%  | 44 MB
 9827345 | users_email        | 18 MB      | t      | email          |   28.67%  | 5160 kB

```

This command displays indexes that contain `NULL` values. A high ratio of `NULL` values means that using a partial index excluding them will be beneficial in case they are not used for searching.

[More info](https://pawelurbanek.com/postgresql-fix-performance#null-indexes)

### `seq_scans`

```rust
struct SeqScans {
    name: String,
    count: i64,
}

seq_scans(schema: Option<String>) -> Result<Vec<SeqScans>, PgExtrasError>

               name                |  count
-----------------------------------+----------
 learning_coaches                  | 44820063
 states                            | 36794975
 grade_levels                      | 13972293
 charities_customers               |  8615277
 charities                         |  4316276
 messages                          |  3922247
 contests_customers                |  2915972
 classroom_goals                   |  2142014
(truncated results for brevity)
```

This command displays the number of sequential scans recorded against all tables, descending by count of sequential scans. Tables that have very high numbers of sequential scans may be under-indexed, and it may be worth investigating queries that read from these tables.

[More info](https://pawelurbanek.com/postgresql-fix-performance#missing-indexes)

### `long_running_queries`

```rust
struct LongRunningQueries {
    pid: String,
    duration: String,
    query: String,
}

long_running_queries() -> Result<Vec<LongRunningQueries>, PgExtrasError> 

  pid  |    duration     |                                      query
-------+-----------------+---------------------------------------------------------------------------------------
 19578 | 02:29:11.200129 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1450645 LIMIT 1
 19465 | 02:26:05.542653 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1889881 LIMIT 1
 19632 | 02:24:46.962818 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1581884 LIMIT 1
(truncated results for brevity)
```

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`.

### `records_rank`

```rust
struct RecordsRank {
    name: String,
    esiimated_count: i64,
}

records_rank(schema: Option<String>) -> Result<Vec<RecordsRank>, PgExtrasError> 

               name                | estimated_count
-----------------------------------+-----------------
 tastypie_apiaccess                |          568891
 notifications_event               |          381227
 core_todo                         |          178614
 core_comment                      |          123969
 notifications_notification        |          102101
 django_session                    |           68078
 (truncated results for brevity)
```

This command displays an estimated count of rows per table, descending by estimated count. The estimated count is derived from `n_live_tup`, which is updated by vacuum operations. Due to the way `n_live_tup` is populated, sparse vs. dense pages can result in estimations that are significantly out from the real count of rows.

### `bloat`

```rust
struct Bloat {
    typefield: String,
    schemaname: String,
    object_name: String,
    bloat: Decimal,
    waste: String,
}

bloat() -> Result<Vec<Bloat>, PgExtrasError> 

 type  | schemaname |           object_name         | bloat |   waste
-------+------------+-------------------------------+-------+----------
 table | public     | bloated_table                 |   1.1 | 98 MB
 table | public     | other_bloated_table           |   1.1 | 58 MB
 index | public     | bloated_table::bloated_index  |   3.7 | 34 MB
 table | public     | clean_table                   |   0.2 | 3808 kB
 table | public     | other_clean_table             |   0.3 | 1576 kB
 (truncated results for brevity)
```

This command displays an estimation of table "bloat" – space allocated to a relation that is full of dead tuples, that has yet to be reclaimed. Tables that have a high bloat ratio, typically 10 or greater, should be investigated to see if vacuuming is aggressive enough, and can be a sign of high table churn.

[More info](https://pawelurbanek.com/postgresql-fix-performance#bloat)

### `vacuum_stats`

```rust
struct VacuumStats {
    schema: String,
    table: String,
    last_vacuum: String,
    last_autovacuum: String,
    rowcount: String,
    dead_rowcount: String,
    autovacuum_threshold: String,
    expect_autovacuum: String,
}

vacuum_stats() -> Result<Vec<VacuumStats>, PgExtrasError> 

 schema |         table         | last_vacuum | last_autovacuum  |    rowcount    | dead_rowcount  | autovacuum_threshold | expect_autovacuum
--------+-----------------------+-------------+------------------+----------------+----------------+----------------------+-------------------
 public | log_table             |             | 2013-04-26 17:37 |         18,030 |              0 |          3,656       |
 public | data_table            |             | 2013-04-26 13:09 |             79 |             28 |             66       |
 public | other_table           |             | 2013-04-26 11:41 |             41 |             47 |             58       |
 public | queue_table           |             | 2013-04-26 17:39 |             12 |          8,228 |             52       | yes
 public | picnic_table          |             |                  |             13 |              0 |             53       |
 (truncated results for brevity)
```

This command displays statistics related to vacuum operations for each table, including an estimation of dead rows, last autovacuum and the current autovacuum threshold. This command can be useful when determining if current vacuum thresholds require adjustments, and to determine when the table was last vacuumed.

### `buffercache_stats`

```rust
struct BuffercacheStats {
    relname: String,
    buffered: String,
    buffer_percent: Decimal,
    percent_of_relation: Decimal,
}

buffercache_stats() -> Result<Vec<BuffercacheStats>, PgExtrasError> 
```

This command shows the relations buffered in database share buffer, ordered by percentage taken. It also shows that how much of the whole relation is buffered.

### `buffercache_usage`

```rust
struct BuffercacheUsage {
    relname: String,
    buffers: i64,
}

buffercache_usage() -> Result<Vec<BuffercacheUsage>, PgExtrasError> 
```

This command calculates how many blocks from which table are currently cached.

### `extensions`

```rust
struct Extensions {
    name: String,
    default_version: String,
    installed_version: String,
    comment: String,
}

extensions() -> Result<Vec<Extensions>, PgExtrasError> 

```

This command lists all the currently installed and available PostgreSQL extensions.

### `connections`

```rust
struct Connections {
    username: String,
    pid: i32,
    client_addr: String,
}

connections() -> Result<Vec<Connections>, PgExtrasError> 

+----------------------------------------------------------------+
|      Returns the list of all active database connections       |
+------------------+--------------------------+------------------+
| username | pid   | client_address           | application_name |
+------------------+--------------------------+------------------+
| postgres | 15962 | 172.31.69.166/32         | sidekiq          |
| postgres | 16810 | 172.31.69.166/32         | bin/rails        |
+------------------+--------------------------+------------------+

```

This command returns the list of all active database connections.

### `mandelbrot`

```rust
struct Mandelbrot {
    array_to_string: String,
}

mandelbrot() -> Result<Vec<Mandelbrot>, PgExtrasError>

```

This command outputs the Mandelbrot set, calculated through SQL.

## Testing

```bash
cp docker-compose.yml.sample docker-compose.yml
docker compose up -d
cargo test -- --nocapture
```

## Query sources

- [https://github.com/heroku/heroku-pg-extras](https://github.com/heroku/heroku-pg-extras)
- [https://hakibenita.com/postgresql-unused-index-size](https://hakibenita.com/postgresql-unused-index-size)
- [https://sites.google.com/site/itmyshare/database-tips-and-examples/postgres/useful-sqls-to-check-contents-of-postgresql-shared_buffer](https://sites.google.com/site/itmyshare/database-tips-and-examples/postgres/useful-sqls-to-check-contents-of-postgresql-shared_buffer)
- [https://wiki.postgresql.org/wiki/Index_Maintenance](https://wiki.postgresql.org/wiki/Index_Maintenance)