Fix typos

Author: borisz

0002_how_to_troubleshoot_and_speedup_postgres_restarts.md

@@ -38,7 +38,7 @@ The second reason – a lot of dirty buffers in the buffer pool – is less triv
 - checkpoint tuning was performed in favor of fewer overheads of bulk random writes and fewer full-page writes (usually meaning that `max_wal_size` and `checkpoint_timeout` are increased)
 - the latest checkpoint happened quite long ago (can be seen in PG logs in `log_checkpoint = on`, which is recommended to have in most cases). 
 
-The amount of dirty buffers is quite easy to observe, using extension pg_buffercache (standard contrib modele) and this query (may take significant time; see [the docs](https://postgresql.org/docs/current/pgbuffercache.html)):
+The amount of dirty buffers is quite easy to observe, using extension pg_buffercache (standard contrib module) and this query (may take significant time; see [the docs](https://postgresql.org/docs/current/pgbuffercache.html)):
 ```sql
 select count(*), pg_size_pretty(count(*) * 8 * 1024)
 from pg_buffercache
@@ -82,4 +82,4 @@ Interestingly, slow/failing `archive_command` can cause longer downtime during s
 
 That's it. Note that we didn't cover various timeouts (e.g., pg_ctl's option `--timeout` and wait behavior `-w`, `-W`, see [Postgres docs](https://postgresql.org/docs/current/app-pg-ctl.html)) here and just discussed what can cause delays in shutdown/restart attempts.
 
-Hope it was helpful - as usual, [subscribe](https://twitter.com/samokhvalov/), like, share, and comment! 💙
+Hope it was helpful - as usual, [subscribe](https://twitter.com/samokhvalov/), like, share, and comment! 💙

0003_how_to_troubleshoot_long_startup.md

@@ -159,7 +159,7 @@ Bonus: how to simulate long startup / REDO time:
 1. Increase the distance between checkpoints raising `max_wal_size` and `checkpoint_timeout` (say, `'100GB'` and `'60min'`)
 2. Create a large table `t1` (say, 10-100M rows): `create table t1 as select i, random() from generate_series(1, 100000000) i;`
 3. Execute a long transaction to data from `t1` (not necessary to finish it): `begin; delete from t1;`
-4. Observe the amount of dirity buffers with extension `pg_buffercache`:
+4. Observe the amount of dirty buffers with extension `pg_buffercache`:
    -  create extension `pg_buffercache`;
    - `select isdirty, count(*), pg_size_pretty(count(*) * 8 * 1024) from pg_buffercache  group by 1 \watch`
 5. When the total size of dirty buffers reaches a few GiB, intentionally crash your server, sending `kill -9 <pid>` using PID of any Postgres backend process.

0004_tuple_sparsenes.md

@@ -136,7 +136,7 @@ Thus, the Postgres executor must handle 88 KiB to return 317 bytes – this is f
 - Index maintenance: bloat control as well + regular reindexing, because index health declines over time even if autovacuum is well-tuned (btree health degradation rates improved in PG14, but those optimization does not eliminate the need to reindex on regular basis in heavily loaded systems).
 - Partitioning: one of benefits of partitioning is improved data locality.
 
-**Option 2.** Use index-only scans instead of index scans. This can be achieved by using mutli-column indexes or covering indexes, to include all the columns needed for our query. For our example:
+**Option 2.** Use index-only scans instead of index scans. This can be achieved by using multi-column indexes or covering indexes, to include all the columns needed for our query. For our example:
 ```
 nik=# create index on t1(user_id) include (id);
 CREATE INDEX

0010_flamegraphs_for_postgres.md

@@ -180,11 +180,11 @@ where i between 1000 and 2000;
 (5 rows)
 ```
 
-In this case, the planning time is really low, sub-millisecond – but I encountered with cases, when planning happened to be extremely slow, many seconds or even dozens of seconds. And it turned out (thanks to flamegraphs!) that analysing the Merge Join paths was the reason, so with "set enable_mergejoin = off" the planning time dropped to very low, sane values. But this is another story.
+In this case, the planning time is really low, sub-millisecond – but I encountered with cases, when planning happened to be extremely slow, many seconds or even dozens of seconds. And it turned out (thanks to flamegraphs!) that analyzing the Merge Join paths was the reason, so with "set enable_mergejoin = off" the planning time dropped to very low, sane values. But this is another story.
 
 ## Some good mate
 - Brendan Gregg's books: "Systems Performance" and "BPF Performance Tools"
-- Brendant Gregg's talks – for example, ["eBPF: Fueling New Flame Graphs & more • Brendan Gregg"](https://youtube.com/watch?v=HKQR7wVapgk) (video, 67 min) 
+- Brendan Gregg's talks – for example, ["eBPF: Fueling New Flame Graphs & more • Brendan Gregg"](https://youtube.com/watch?v=HKQR7wVapgk) (video, 67 min) 
 - [Profiling with perf](https://wiki.postgresql.org/wiki/Profiling_with_perf) (Postgres wiki)
 
 ---

0012_from_pgss_to_explain__how_to_find_query_examples.md

@@ -99,7 +99,7 @@ TBD:
 - tricks for versions <16
 
 ## Summary
-- In PG14+, use `compute_query_id` to have quer`y_id values both in Postgres logs and `pg_stat_activity`
+- In PG14+, use `compute_query_id` to have query_id values both in Postgres logs and `pg_stat_activity`
 - Increase `track_activity_query_size` (requires restart) to be able to track larger queries in `pg_stat_activity`
 - Organize workflow to combine records from `pg_stat_statements` and query examples from logs and `pg_stat_activity`, so when it comes to query optimization, you have good examples ready to be used with `EXPLAIN (ANALYZE, BUFFERS)`.
 

0016_how_to_get_into_trouble_using_some_postgres_features.md

@@ -48,7 +48,7 @@ A couple of tips – how to make your code NULL-safe:
 - For comparison, instead of `=` or `<>`: `IS [NOT] DISTINCT FROM` (check out the `EXPLAIN` plan though).
 - Instead of concatenation, use: `format('%s %s', var1, var2)`.
 - Don't use `WHERE NOT IN (SELECT ...)` – use `NOT EXISTS` instead (
-  see thia [JOOQ blog post](https://jooq.org/doc/latest/manual/reference/dont-do-this/dont-do-this-sql-not-in/)).
+  see this [JOOQ blog post](https://jooq.org/doc/latest/manual/reference/dont-do-this/dont-do-this-sql-not-in/)).
 - Just be careful. `NULL`s are treacherous.
 
 ## Subtransactions under heavy loads

0019_how_to_import_csv_to_postgres.md

@@ -123,7 +123,7 @@ nik=# select clock_timestamp, pid, query from slow_tx_from_csv_1 order by clock_
 ## Method 2: Query CSV data live via file_fdw
 
 This method should be used when we need to query the CSV file data via SQL "live" without loading a snapshot. To achieve
-this, we'll be using [file_fwd](https://postgresql.org/docs/current/file-fdw.html).
+this, we'll be using [file_fdw](https://postgresql.org/docs/current/file-fdw.html).
 
 Having a great advantage (live data!), this method has its obvious disadvantages:
 

0023_how_to_use_openai_apis_in_postgres.md

@@ -176,7 +176,7 @@ Here's a straightforward example of using semantic search to find the most relev
 The concept here is straightforward:
 
 1. First, we call OpenAI API to "vectorize" the text of our request.
-2. Then, we use `pgvector`'s similarity search to find K nearest neighbours.
+2. Then, we use `pgvector`'s similarity search to find K nearest neighbors.
 
 We will use the `HNSW` index, considered one of the best approaches today (although originally described in
 [2016](https://arxiv.org/abs/1603.09320)); added in by many DBMSes. In `pgvector`, it was added in version 0.5.0. 

0040_how_to_break_a_database_part_2_simulate_xid_wraparound.md

@@ -140,7 +140,7 @@ Everyone should not only monitor (with alerting) for traditional XID wraparound
 risks. And it should be included in the snippets showing how much of the "capacity" is used.
 
 > 🎯 **TODO:** snippet to show both XID w-d and MultiXID w-d, at both DB and table level
-> Obviously, multixid wraparrounds are encountered less often in the wild – I don't see people have `datminmxid` and
+> Obviously, multixid wraparounds are encountered less often in the wild – I don't see people have `datminmxid` and
 > `relminmxid` used in the snippets.
 > Basic version:
 >

0059_psql_tuning.md

@@ -51,7 +51,7 @@ After installation:
 
 To install:
 
-- on macOS/homebrew: `brew install pspg`
+- on macOS/Homebrew: `brew install pspg`
 - Ubuntu/Debian: `sudo apt update && sudo apt install -y pspg`
 
 Then:

0065_uuid_v7_and_partitioning_timescaledb.md

@@ -228,7 +228,7 @@ test=# explain select * from my_table
 
 ## Postscript
 
-Also read the following comment by [@jamessewell](https://twitter.com/jamessewell), originaly posted
+Also read the following comment by [@jamessewell](https://twitter.com/jamessewell), originally posted
 [here](https://twitter.com/jamessewell/status/1730125437903450129):
 
 > If update your `create_hypertable` call with: