README.md in rails-pg-extras-1.2.4 vs README.md in rails-pg-extras-1.3.0

@@ -14,10 +14,12 @@
 
 - [Elixir](https://github.com/pawurb/ecto_psql_extras)
 
 - [Python](https://github.com/pawurb/ecto_psql_extras)
 
+- [Haskell](https://github.com/pawurb/haskell-pg-extras)
+
 ## Installation
 
 In your Gemfile
 
 ```ruby
@@ -104,11 +106,11 @@
 | 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 seperately.
+The same as `cache_hit` with each table's indexes cache hit info displayed separately.
 
 ### `table_cache_hit`
 
 ```
 
@@ -155,11 +157,11 @@
          |         |               |         |    select            +|                  |
          |         |               |         |      pg_stat_activi   |                  |
 (4 rows)
 ```
 
-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.
+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`
 
 ```
 $ rake pg_extras:all_locks
@@ -181,11 +183,11 @@
  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
 (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 filesystem).
+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.
 
 ### `calls`
 
@@ -281,11 +283,11 @@
  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 calcualtes by using the system administration function `pg_indexes_size()`.
+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`
 
 ```
 $ rake pg_extras:total_table_size
@@ -341,11 +343,11 @@
  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 underindexed, and it may be worth investigating queries that read from these tables.
+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`
 
 ```
 $ rake pg_extras:long_running_queries
@@ -407,10 +409,10 @@
  public | other_table           |             | 2013-04-26 11:41 |             41 |             47 |             58       |
  public | queue_table           |             | 2013-04-26 17:39 |             12 |          8,228 |             52       | yes
  (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.
+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.
 
 ### `kill_all`
 
 ```ruby