README.md in rails-pg-extras-1.5.0 vs README.md in rails-pg-extras-1.5.1
- old
+ new
@@ -88,10 +88,12 @@
## Available methods
### `cache_hit`
```
+RailsPGExtras.cache_hit
+
$ rake pg_extras:cache_hit
name | ratio
----------------+------------------------
index hit rate | 0.99957765013541945832
@@ -103,10 +105,12 @@
### `index_cache_hit`
```
+RailsPGExtras.index_cache_hit
+
$ rake pg_extras:index_cache_hit
| name | buffer_hits | block_reads | total_read | ratio |
+-----------------------+-------------+-------------+------------+-------------------+
| teams | 187665 | 109 | 187774 | 0.999419514948821 |
@@ -119,10 +123,12 @@
### `table_cache_hit`
```
+RailsPGExtras.table_cache_hit
+
$ rake pg_extras:table_cache_hit
| name | buffer_hits | block_reads | total_read | ratio |
+-----------------------+-------------+-------------+------------+-------------------+
| plans | 32123 | 2 | 32125 | 0.999937743190662 |
@@ -134,10 +140,12 @@
The same as `cache_hit` with each table's cache hit info displayed seperately.
### `index_usage`
```
+RailsPGExtras.index_usage
+
$ rake pg_extras:index_usage
relname | percent_of_times_index_used | rows_in_table
---------------------+-----------------------------+---------------
events | 65 | 1217347
@@ -151,10 +159,12 @@
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`
```
+RailsPGExtras.locks
+
$ rake pg_extras:locks
procpid | relname | transactionid | granted | query_snippet | mode | age
---------+---------+---------------+---------+-----------------------+-------------------------------------
31776 | | | t | <IDLE> in transaction | ExclusiveLock | 00:19:29.837898
@@ -169,18 +179,22 @@
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.
### `all_locks`
```
+RailsPGExtras.all_locks
+
$ rake pg_extras:all_locks
```
This command displays all the current locks, regardless of their type.
### `outliers`
```
+RubyPGExtras.outliers(args: { limit: 20 })
+
$ rake pg_extras:outliers
qry | 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
@@ -197,10 +211,12 @@
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.
### `calls`
```
+RubyPGExtras.calls(args: { limit: 10 })
+
$ rake pg_extras:calls
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
@@ -214,10 +230,12 @@
This command is much like `pg:outliers`, but ordered by the number of times a statement has been called.
### `blocking`
```
+RubyPGExtras.blocking
+
$ rake pg_extras:blocking
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
@@ -227,10 +245,12 @@
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.
#### `total_index_size`
```
+RubyPGExtras.total_index_size
+
$ rake pg_extras:total_index_size
size
-------
28194 MB
@@ -240,10 +260,12 @@
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`
```
+RubyPGExtras.index_size
+
$ rake pg_extras:index_size
name | size
---------------------------------------------------------------+---------
idx_activity_attemptable_and_type_lesson_enrollment | 5196 MB
index_enrollment_attemptables_by_attempt_and_last_in_group | 4045 MB
@@ -261,10 +283,12 @@
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`
```
+RubyPGExtras.table_size
+
$ rake pg_extras:table_size
name | size
---------------------------------------------------------------+---------
learning_coaches | 196 MB
@@ -278,10 +302,12 @@
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`
```
+RubyPGExtras.table_indexes_size
+
$ rake pg_extras:table_indexes_size
table | indexes_size
---------------------------------------------------------------+--------------
learning_coaches | 153 MB
@@ -295,10 +321,12 @@
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`
```
+RubyPGExtras.total_table_size
+
$ rake pg_extras:total_table_size
name | size
---------------------------------------------------------------+---------
learning_coaches | 349 MB
@@ -312,10 +340,12 @@
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`
```
+RubyPGExtras.unused_indexes(args: { min_scans: 20 })
+
$ rake pg_extras:unused_indexes
table | index | index_size | index_scans
---------------------+--------------------------------------------+------------+-------------
public.grade_levels | index_placement_attempts_on_grade_level_id | 97 MB | 0
@@ -328,10 +358,12 @@
### `null_indexes`
```ruby
+RailsPGExtras.null_indexes(args: { min_relation_size_mb: 10 })
+
$ rake pg_extras:null_indexes
oid | index | index_size | unique | indexed_column | null_frac | expected_saving
---------+--------------------+------------+--------+----------------+-----------+-----------------
183764 | users_reset_token | 1445 MB | t | reset_token | 97.00% | 1401 MB
@@ -343,10 +375,12 @@
This commands 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. [Source and more info](https://hakibenita.com/postgresql-unused-index-size).
### `seq_scans`
```
+RubyPGExtras.seq_scans
+
$ rake pg_extras:seq_scans
name | count
-----------------------------------+----------
learning_coaches | 44820063
@@ -371,10 +405,12 @@
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.
### `long_running_queries`
```
+RubyPGExtras.long_running_queries(args: { threshold: "200 milliseconds" })
+
$ rake pg_extras:long_running_queries
pid | duration | query
-------+-----------------+---------------------------------------------------------------------------------------
19578 | 02:29:11.200129 | EXPLAIN SELECT "students".* FROM "students" WHERE "students"."id" = 1450645 LIMIT 1
@@ -386,10 +422,12 @@
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`
```
+RubyPGExtras.records_rank
+
$ rake pg_extras:records_rank
name | estimated_count
-----------------------------------+-----------------
tastypie_apiaccess | 568891
@@ -404,10 +442,12 @@
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`
```
+RubyPGExtras.bloat
+
$ rake pg_extras:bloat
type | schemaname | object_name | bloat | waste
-------+------------+-------------------------------+-------+----------
table | public | bloated_table | 1.1 | 98 MB
@@ -421,10 +461,12 @@
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.
### `vacuum_stats`
```
+RubyPGExtras.vacuum_stats
+
$ rake pg_extras:vacuum_stats
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 |
@@ -446,20 +488,27 @@
This commands kills all the currently active connections to the database. It can be useful as a last resort when your database is stuck in a deadlock.
### `extensions`
-```ruby
+```
RailsPGExtras.extensions
+$ rake pg_extras:extensions
+
+| pg_stat_statements | 1.7 | 1.7 | track execution statistics of all SQL statements executed
+ (truncated results for brevity)
+
```
This command lists all the currently installed and available PostgreSQL extensions.
### mandelbrot
```
+RailsPGExtras.mandelbrot
+
$ rake pg_extras:mandelbrot
```
This command outputs the Mandelbrot set, calculated through SQL.