Merge branch 'bz/typos' into 'main'

Fix EOL, EOF, typos and a correction

See merge request postgres-ai/postgresql-consulting/postgres-howtos!31

Author: NikolayS

0001_explain_analyze_buffers.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1706689567355732052), [LinkedIn post](https://www.linkedin.com/feed/update/urn:li:activity:7112529621178347520/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1706689567355732052), [LinkedIn post](https://www.linkedin.com/feed/update/urn:li:activity:7112529621178347520/).
 
 ---
 
@@ -44,4 +44,4 @@ Don't think about the timing numbers when you're inside the optimization process
 
 Finally, when optimizing a query, if you managed to reduce the BUFFERS numbers, this means that to execute this query, Postgres will need fewer buffers in the buffer pool involved, reducing IO, minimizing risks of contention, and leaving more space in the buffer pool for something else. Following this approach may eventually provide a global positive effect for the general performance of your database.
 
-A blog post on this topic: [EXPLAIN (ANALYZE) needs BUFFERS to improve the Postgres query optimization process](https://postgres.ai/blog/20220106-explain-analyze-needs-buffers-to-improve-the-postgres-query-optimization-process)
+A blog post on this topic: [EXPLAIN (ANALYZE) needs BUFFERS to improve the Postgres query optimization process](https://postgres.ai/blog/20220106-explain-analyze-needs-buffers-to-improve-the-postgres-query-optimization-process)

0002_how_to_troubleshoot_and_speedup_postgres_restarts.md

@@ -1,12 +1,12 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1707147450044297673), [LinkedIn post](https://www.linkedin.com/pulse/how-troubleshoot-speed-up-postgres-stop-restart-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1707147450044297673), [LinkedIn post](https://www.linkedin.com/pulse/how-troubleshoot-speed-up-postgres-stop-restart-nikolay-samokhvalov/).
 
 ---
 
 # How to troubleshoot and speed up Postgres stop and restart attempts
 
 <img src="files/0002_cover.png" width="600" />
 
-#PostgresMarathon day 2. Let's discuss PostgreSQL shutdown and restarts. It's not uncommon to see quite long and even failed shutdown/restart attempts. If it's happening inside an incident troubleshooting, it often can provoke emotions and additional mistakes. 
+#PostgresMarathon day 2. Let's discuss PostgreSQL shutdown and restarts. It's not uncommon to see quite long and even failed shutdown/restart attempts. If it's happening inside an incident troubleshooting, it often can provoke emotions and additional mistakes.
 
 Some very popular reasons affecting the duration of the shutdown attempt:
 1. There are long-running transactions.
@@ -34,11 +34,11 @@ In this case, it is usually recommended to use `SIGINT` (`pg_ctl stop -m fast`)
 ## Reason 2: Long shutdown checkpoint
 
 The second reason – a lot of dirty buffers in the buffer pool – is less trivial but fortunately, is easy to mitigate. This is especially common when:
-- the buffer pool size (`shared_buffers`) is large 
+- the buffer pool size (`shared_buffers`) is large
 - 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 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
@@ -76,10 +76,10 @@ Interestingly, slow/failing `archive_command` can cause longer downtime during s
 ## Summary:
 - use "fast mode" (`pg_ctl stop -m fast`) if you don't want existing sessions to end their work normally
 - always perform an explicit CHECKPOINT before shutdown or restart attempt
-- monitor `pg_stat_archiver` and ensure that `pg_stat_archiver` works without failures and lags 
+- monitor `pg_stat_archiver` and ensure that `pg_stat_archiver` works without failures and lags
 
 ---
 
 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

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1707466169245171773), [LinkedIn post](https://www.linkedin.com/pulse/how-troubleshoot-long-postgres-startup-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1707466169245171773), [LinkedIn post](https://www.linkedin.com/pulse/how-troubleshoot-long-postgres-startup-nikolay-samokhvalov/).
 
 ---
 
@@ -42,7 +42,7 @@ One of the biggest causes of frustration can be a lack of understanding of what'
 ### 2a. Check max_wal_size and checkpoint_timeout
 The settings that matter the most here are related to checkpoint tuning. If `max_wal_size` and `checkpoint_timeout` are tuned so checkpoints happen less often, Postgres needs more time to reach a consistency point, if shutdown was not clean, without successful shutdown checkpoint (e.g., VM restarted) or if you're restoring from backups. To learn more about this:
 - [official docs](https://postgresql.org/docs/current/sql-checkpoint.html) (official docs)
-- [WAL and checkpoint tuning](https://postgres.fm/episodes/wal-and-checkpoint-tuning) (Postgres.fm podcast) 
+- [WAL and checkpoint tuning](https://postgres.fm/episodes/wal-and-checkpoint-tuning) (Postgres.fm podcast)
 
 In other words, if you observe longer startup time, it's probably because the server was tuned to write less to WAL and sync buffers less often during heavy loads at normal times – that tuning comes for the price of longer startup time, and this is exactly what you're dealing with.
 
@@ -98,7 +98,7 @@ A little bit later:
 99887   ??  Us     0:02.29 postgres: startup recovering 000000010000004500000058
 ```
 
-– as we can see, the position is changing, so REDO is progressing. This is already useful and should give some relief. 
+– as we can see, the position is changing, so REDO is progressing. This is already useful and should give some relief.
 
 Now, we cannot use SQL, but we can use `pg_controldata` to see meta information about the cluster's state (you need to specify PGDATA location, using `-D`):
 
@@ -159,14 +159,14 @@ 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.
 6. Ensure Postgres is down: `ps ax | grep postgres`
 7. Start Postgres (e.g., `pg_ctl -D <PGDATA> start`)
 8. Check Postgres logs and ensure that REDO is happening.
-   
+
 ---
 
 That's it! I hope this helps keep you calm and allows you to wait consciously for your Postgres to open the gates to fun SQL queries. Hopefully, fewer folks will be stressed out during long startup times.

0004_tuple_sparsenes.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1707854750392455596), [LinkedIn post](https://www.linkedin.com/pulse/understanding-how-sparsely-tuples-stored-postgres-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1707854750392455596), [LinkedIn post](https://www.linkedin.com/pulse/understanding-how-sparsely-tuples-stored-postgres-nikolay-samokhvalov/).
 
 ---
 
@@ -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
@@ -188,4 +188,4 @@ That's it for today – we discussed ctid. Sometime in the future, we'll continu
 
 [Subscribe](https://twitter.com/samokhvalov), share, like!
 
-Not to forget, I'm mirroring these tips in this GitLab repo: https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/
+Not to forget, I'm mirroring these tips in this GitLab repo: https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/

0005_pg_stat_statements_part_1.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1708244676313317635), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatments-part-1-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1708244676313317635), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatments-part-1-nikolay-samokhvalov/).
 
 ---
 
@@ -16,7 +16,7 @@ Today we focus on how to read and use [pg_stat_statements](https://postgresql.or
 ## pg_stat_statements basics
 Extension `pg_stat_statements` (for short, "pgss") became standard de-facto for macro-analysis.
 
-It tracks all queries, aggregating them to query groups – called "normalized queries" – where parameters are 
+It tracks all queries, aggregating them to query groups – called "normalized queries" – where parameters are
 removed.
 
 There are certain limitations, some of which are worth remembering:
@@ -62,7 +62,7 @@ If your monitoring system supports pgss, you don't need to deal with working wit
 
 Assuming you successfully obtained 2 snapshots of pgss (remembering timestamp when they were collected) or use proper monitoring tool, let's consider practical meaning of the three derivatives we discussed.
 
-## Derivative 1. Time-based differentiation 
+## Derivative 1. Time-based differentiation
 * `dM/dt`, where `M` is `calls` – the meaning is simple. It's QPS (queries per second). If we talk about particular group (normalized query), it's that all queries in this group have. `10,000` is pretty large so, probably, you need to improve the client (app) behavior to reduce it, `10` is pretty small (of course, depending on situation). If we consider this derivative for whole node, it's our "global QPS".
 
 * `dM/dt`, where `M` is `total_plan_time + total_exec_time` – this is the most interesting and key metric in query macro analysis targeted at resource consumption optimization (goal: reduce time spent by server to process queries). Interesting fact: it is measured in "seconds per second", meaning: how many seconds our server spends to process queries in this query group. *Very* rough (but illustrative) meaning: if we have `2 sec/sec` here, it means that we spend 2 seconds each second to process such queries – we definitely would like to have more than 2 vCPUs to do that. Although, this is a very rough meaning because pgss doesn't distinguish situations when query is waiting for some lock acquisition vs. performing some actual work in CPU (for that, we need to involve wait event analysis) – so there may be cases when the value here is high not having a significant effect on the CPU load.

0006_pg_stat_statements_part_2.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1708692950006612277), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatements-part-2-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1708692950006612277), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatements-part-2-nikolay-samokhvalov/).
 
 ---
 
@@ -8,7 +8,7 @@ Previous post: [0005_pg_stat_statements_part_1.md](./0005_pg_stat_statements_par
 
 <img src="files/0006_cover.png" width="600" />
 
-Yesterday we discussed some basics of working with pgss, and the first set of derived metrics, `dM/dt` – time-based differentiation. Today we'll focus on the second set: `dM/dc`, where `c` is the number of calls (column `calls` in pgss). 
+Yesterday we discussed some basics of working with pgss, and the first set of derived metrics, `dM/dt` – time-based differentiation. Today we'll focus on the second set: `dM/dc`, where `c` is the number of calls (column `calls` in pgss).
 
 ## Derivative 2. Calls-based differentiation
 This set of metrics is not less important than time-based differentiation because it can provide you systematic view on characteristics of your workload and be a good tool for macro-optimization of query performance.
@@ -44,4 +44,4 @@ Let's consider the meanings of various derived metrics obtained in such way:
 
 ---
 
-Tomorrow, we'll finish with step 3 of this pgss-related how-to.
+Tomorrow, we'll finish with step 3 of this pgss-related how-to.

0007_pg_stat_statements_part_3.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1709069225762095258), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatements-part-3-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1709069225762095258), [LinkedIn post](https://www.linkedin.com/pulse/how-work-pgstatstatements-part-3-nikolay-samokhvalov/).
 
 ---
 
@@ -24,7 +24,7 @@ Analysis of relative values helps understand how big is the potential win from e
 - However,  if we have `1000 calls/sec` and see that it's `50%` of the whole, this single optimization step — say, reducing it to `10 calls/sec` — helps us shave off almost half of all the QPS we have.
 
 One of the ways to deal with proportion values in larger systems is to react on large percentage values, consider the corresponding query groups as candidates for optimization. For example, in systems with large number of query groups, it might make sense to apply the following approach:
-- Periodically, for certain metrics (for example, `calls`, `total_exec_time`, `total_plan_time`, `shared_blks_dirtied`, `wal_bytes`), build Top-10 lists showing query groups having the largest `%M` values. 
+- Periodically, for certain metrics (for example, `calls`, `total_exec_time`, `total_plan_time`, `shared_blks_dirtied`, `wal_bytes`), build Top-10 lists showing query groups having the largest `%M` values.
 - If particular query group turns out to be a major contributor – say, >20% — on certain metrics, consider this query as a candidate for optimization. For example, in most cases, we don't want a single query group to be responsible for 1/2 of the aggregated `total_exec_time` ("total `total_exec_time`", apologies for tautology).
 – In certain cases, it is ok to decide that query doesn't require optimization — in this case we mark such group as exclusion and skip it in the next analyses.
 
@@ -36,7 +36,7 @@ If we deal with 2 snapshots, then it makes sense to obtain such values explicitl
 1. `%M`, where `M` is `calls` — this gives us proportions of QPS. For example, if we normally have `~10k QPS`, but if some query group is responsible for `~7k QPS`, this might be considered as abnormal, requiring optimizations on client side (usually, application code).
 
 2. `%M`, where `M` is `total_plan_time + total_exec_time` — percentage in time that the server spends to process queries in a particular group. For example, if the absolute value is `20 seconds/second` (quite a loaded system — each second Postgres needs to spend 20 seconds to process queries), and a particular group has 75% on this metric, it means we need to focus on optimizing this particular query group. Ways to optimize:
-    - If QPS (`calls/second`) is high, then, first of all, we need to reduce. 
+    - If QPS (`calls/second`) is high, then, first of all, we need to reduce.
     - If average latency (`total_exec_time`, less often `total_plan_time` or both) is high, then we need to apply micro-optimization using `EXPLAIN` and `EXPLAIN (ANALYZE, BUFFERS)`.
     - In some cases, we need to combine both directions of optimization.
 

0008_how_to_speed_up_pg_dump.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1709490130749378796), [LinkedIn post](https://www.linkedin.com/pulse/how-speed-up-pgdump-when-dumping-large-postgres-nikolay-samokhvalov/). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1709490130749378796), [LinkedIn post](https://www.linkedin.com/pulse/how-speed-up-pgdump-when-dumping-large-postgres-nikolay-samokhvalov/).
 
 ---
 
@@ -134,4 +134,4 @@ A good post about dealing with snapshots when making database dumps: ["Postgres
 
 ---
 
-That's it for today. Good dumping speeds in production (2+ TiB/h) to everyone!
+That's it for today. Good dumping speeds in production (2+ TiB/h) to everyone!

0009_lsn_values_and_wal_filenames.md

@@ -1,4 +1,4 @@
-Originally from: [tweet](https://twitter.com/samokhvalov/status/1709818510787162429), [LinkedIn post](...). 
+Originally from: [tweet](https://twitter.com/samokhvalov/status/1709818510787162429), [LinkedIn post](...).
 
 ---
 
@@ -86,4 +86,4 @@ This can be very helpful if you need to work with LSN values or WAL filenames or
 
 ---
 
-Thanks for reading! As usual: please share it with your colleagues and friends who work with #PostgreSQL.
+Thanks for reading! As usual: please share it with your colleagues and friends who work with #PostgreSQL.