README.md in rails-pg-extras-1.0.0 vs README.md in rails-pg-extras-1.1.0

- old
+ new

@@ -4,19 +4,19 @@ Included rake tasks and Ruby methods 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. Ruby API enables developers to easily integrate the tool into e.g. automatic monitoring tasks. Not using Rails? Check out the core dependency [pure Ruby version](https://github.com/pawurb/ruby-pg-extras). -### Installation +## Installation In your Gemfile ```ruby -gem 'rails-pg-extras' +gem "rails-pg-extras" ``` -### Usage +## Usage Each command can be used as a rake task, or a directly from the Ruby code. ```bash rake pg_extras:cache_hit @@ -51,13 +51,13 @@ RailsPGExtras.cache_hit(in_format: :raw) => #<PG::Result:0x00007f75777f7328 status=PGRES_TUPLES_OK ntuples=2 nfields=2 cmd_tuples=2> ``` -### Available methods +## Available methods -#### `cache_hit` +### `cache_hit` ``` $ rake pg_extras:cache_hit name | ratio @@ -67,11 +67,11 @@ (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. -#### `index_cache_hit` +### `index_cache_hit` ``` $ rake pg_extras:index_cache_hit @@ -83,11 +83,11 @@ (truncated results for brevity) ``` The same as `cache_hit` with each table's indexes cache hit info displayed seperately. -#### `table_cache_hit` +### `table_cache_hit` ``` $ rake pg_extras:table_cache_hit @@ -99,11 +99,11 @@ (truncated results for brevity) ``` The same as `cache_hit` with each table's cache hit info displayed seperately. -#### `index_usage` +### `index_usage` ``` $ rake pg_extras:index_usage relname | percent_of_times_index_used | rows_in_table @@ -320,11 +320,11 @@ (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 underindexed, and it may be worth investigating queries that read from these tables. -### long_running_queries +### `long_running_queries` ``` $ rake pg_extras:long_running_queries pid | duration | query @@ -335,11 +335,11 @@ (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 +### `records_rank` ``` $ rake pg_extras:records_rank name | estimated_count @@ -353,11 +353,11 @@ (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 +### `bloat` ``` $ rake pg_extras:bloat type | schemaname | object_name | bloat | waste @@ -370,11 +370,11 @@ (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. -### vacuum_stats +### `vacuum_stats` ``` $ rake pg_extras:vacuum_stats schema | table | last_vacuum | last_autovacuum | rowcount | dead_rowcount | autovacuum_threshold | expect_autovacuum @@ -386,10 +386,20 @@ (truncated results for brevity) ``` This command displays statistics related to vacuum operations for each table, including an estiamtion 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. +### `kill_all` + +```ruby + +RailsPGExtras.kill_all + +``` + +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. + ### mandelbrot ``` $ rake pg_extras:mandelbrot ``` @@ -399,9 +409,5 @@ ## FAQ * Does is not violate the Heroku PG Extras license? The original plugin is MIT based so it means that copying and redistribution in any format is permitted. - -## Disclaimer - -This tool is in beta state.