postgrespro
diff --git a/‎README.md
Copy file name to clipboardExpand all lines: README.md
+5-5Lines changed: 5 additions & 5 deletions b/‎README.md
Copy file name to clipboardExpand all lines: README.md
+5-5Lines changed: 5 additions & 5 deletions
diff --git a/‎docs/benchmark.md
Copy file name to clipboardExpand all lines: docs/benchmark.md
+2-2Lines changed: 2 additions & 2 deletions b/‎docs/benchmark.md
Copy file name to clipboardExpand all lines: docs/benchmark.md
+2-2Lines changed: 2 additions & 2 deletions
@@ -75,7 +75,7 @@ Example:
 select zson_learn('{{"table1", "col1"}, {"table2", "col2"}}');
 ```
 
-You can create a temporary table and write some common JSONB documents to it manually or use existing tables. The idea is to provide a subset of real data. Lets say some document *type* is twice as frequent as some other document type. ZSON expects that there will be twice more documents of the first type than of the second in a learning set.
+You can create a temporary table and write some common JSONB documents to it manually or use existing tables. The idea is to provide a subset of real data. Lets say some document *type* is twice as frequent as some other document type. ZSON expects that there will be twice as many documents of the first type as those of the second one in a learning set.
 
 Resulting dictionary could be examined using this query:
 
@@ -97,17 +97,17 @@ zson_test=# select x -> 'aaa' from zson_example;
 ?column? | 123
 ```
 
-## Migrating to new dictionary
+## Migrating to a new dictionary
 
 When schema of JSONB documents evolve ZSON could be *re-learned*:
 
 ```
 select zson_learn('{{"table1", "col1"}, {"table2", "col2"}}');
 ```
 
-This time *second* dictionary will be created. Dictionaries are cached in memory so it will take about a minute before ZSON realizes that there is a new dictionary. After that old documents will be decompressed using old dictionary and new documents will be compressed and decompressed using new dictionary.
+This time *second* dictionary will be created. Dictionaries are cached in memory so it will take about a minute before ZSON realizes that there is a new dictionary. After that old documents will be decompressed using the old dictionary and new documents will be compressed and decompressed using the new dictionary.
 
-To find out which dictionary is used for given ZSON document use zson_info procedure:
+To find out which dictionary is used for a given ZSON document use zson_info procedure:
 
 ```
 zson_test=# select zson_info(x) from test_compress where id = 1;
@@ -119,7 +119,7 @@ zson_test=# select zson_info(x) from test_compress where id = 2;
 zson_info | zson version = 0, dict version = 0, ...
 ```
 
-If **all** ZSON documents are migrated to new dictionary the old one could be safely removed:
+If **all** ZSON documents are migrated to the new dictionary the old one could be safely removed:
 
 ```
 delete from zson_dict where dict_id = 0;
 
@@ -319,9 +319,9 @@ tps = 1086.396431 (excluding connections establishing)
 
 In this case ZSON gives about 11.8% more TPS.
 
-We can modify compress.pgbench and nocompress.pgbench so only documents with id in between of 1 and 3000 will be requested. It will simulate a case when all data *does* fit into memory. In this case we see 141K TPS (JSONB) vs 134K TPS (ZSON) which is 5% slower.
+We can modify compress.pgbench and nocompress.pgbench so only the documents with id between 1 and 3000 will be requested. It will simulate a case when all data *does* fit into memory. In this case we see 141K TPS (JSONB) vs 134K TPS (ZSON) which is 5% slower.
 
-Compression ratio could be different depending on documents, database schema, number of rows, etc. But in general ZSON compression is much better than build-in PostgreSQL compression (PGLZ):
+The compression ratio could be different depending on the documents, the database schema, the number of rows, etc. But in general ZSON compression is much better than build-in PostgreSQL compression (PGLZ):
 
 ```
    before   |   after    |      ratio