README.md in rails-pg-extras-1.5.2 vs README.md in rails-pg-extras-1.5.3

- old
+ new

@@ -87,11 +87,11 @@ ## Available methods ### `cache_hit` -``` +```ruby RailsPGExtras.cache_hit $ rake pg_extras:cache_hit name | ratio @@ -101,13 +101,15 @@ (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` -``` +```ruby RailsPGExtras.index_cache_hit $ rake pg_extras:index_cache_hit @@ -119,13 +121,15 @@ (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` -``` +```ruby RailsPGExtras.table_cache_hit $ rake pg_extras:table_cache_hit @@ -137,13 +141,35 @@ (truncated results for brevity) ``` The same as `cache_hit` with each table's cache hit info displayed seperately. -### `index_usage` +[More info](https://pawelurbanek.com/postgresql-fix-performance#cache-hit) +### `db_settings` + +```ruby + +RailsPGExtras.db_settings + +$ rake pg_extras:db_settings + + 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. + +### `index_usage` + +```ruby RailsPGExtras.index_usage $ rake pg_extras:index_usage relname | percent_of_times_index_used | rows_in_table @@ -158,11 +184,11 @@ 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` -``` +```ruby RailsPGExtras.locks $ rake pg_extras:locks procpid | relname | transactionid | granted | query_snippet | mode | age @@ -176,23 +202,25 @@ (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` -``` +```ruby RailsPGExtras.all_locks $ rake pg_extras:all_locks ``` This command displays all the current locks, regardless of their type. ### `outliers` -``` +```ruby RubyPGExtras.outliers(args: { limit: 20 }) $ rake pg_extras:outliers qry | exec_time | prop_exec_time | ncalls | sync_io_time @@ -208,13 +236,15 @@ 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` -``` +```ruby RubyPGExtras.calls(args: { limit: 10 }) $ rake pg_extras:calls qry | exec_time | prop_exec_time | ncalls | sync_io_time @@ -227,13 +257,15 @@ (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` -``` +```ruby RubyPGExtras.blocking $ rake pg_extras:blocking blocked_pid | blocking_statement | blocking_duration | blocking_pid | blocked_statement | blocked_duration @@ -242,13 +274,15 @@ (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. -#### `total_index_size` +[More info](https://pawelurbanek.com/postgresql-fix-performance#deadlocks) -``` +### `total_index_size` + +```ruby RubyPGExtras.total_index_size $ rake pg_extras:total_index_size size @@ -259,11 +293,11 @@ 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` -``` +```ruby RubyPGExtras.index_size $ rake pg_extras:index_size name | size ---------------------------------------------------------------+--------- @@ -282,11 +316,11 @@ 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` -``` +```ruby RubyPGExtras.table_size $ rake pg_extras:table_size name | size @@ -301,11 +335,11 @@ 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` -``` +```ruby RubyPGExtras.table_indexes_size $ rake pg_extras:table_indexes_size table | indexes_size @@ -320,11 +354,11 @@ 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` -``` +```ruby RubyPGExtras.total_table_size $ rake pg_extras:total_table_size name | size @@ -339,11 +373,11 @@ 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` -``` +```ruby RubyPGExtras.unused_indexes(args: { min_scans: 20 }) $ rake pg_extras:unused_indexes table | index | index_size | index_scans @@ -354,10 +388,12 @@ (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) + ### `null_indexes` ```ruby RailsPGExtras.null_indexes(args: { min_relation_size_mb: 10 }) @@ -370,15 +406,17 @@ 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 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). +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` -``` +```ruby RubyPGExtras.seq_scans $ rake pg_extras:seq_scans name | count @@ -389,26 +427,20 @@ charities_customers | 8615277 charities | 4316276 messages | 3922247 contests_customers | 2915972 classroom_goals | 2142014 - contests | 1370267 - goals | 1112659 - districts | 158995 - rollup_reports | 115942 - customers | 93847 - schools | 92984 - classrooms | 92982 - customer_settings | 91226 (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` -``` +```ruby RubyPGExtras.long_running_queries(args: { threshold: "200 milliseconds" }) $ rake pg_extras:long_running_queries pid | duration | query @@ -421,11 +453,11 @@ 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` -``` +```ruby RubyPGExtras.records_rank $ rake pg_extras:records_rank name | estimated_count @@ -441,11 +473,11 @@ 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` -``` +```ruby RubyPGExtras.bloat $ rake pg_extras:bloat type | schemaname | object_name | bloat | waste @@ -458,13 +490,15 @@ (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` -``` +```ruby RubyPGExtras.vacuum_stats $ rake pg_extras:vacuum_stats schema | table | last_vacuum | last_autovacuum | rowcount | dead_rowcount | autovacuum_threshold | expect_autovacuum @@ -488,11 +522,11 @@ 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 @@ -503,10 +537,10 @@ This command lists all the currently installed and available PostgreSQL extensions. ### mandelbrot -``` +```ruby RailsPGExtras.mandelbrot $ rake pg_extras:mandelbrot ```