Changes to pgtune docs

I experienced that it may be better to tell pgtune you have lower resoures than what you have when you have other services running.
I added that now.

I also moved the examples as part of the pgtune section.

diff --git a/docs/docs/configuration/postgresql.md b/docs/docs/configuration/postgresql.md
index 32ea97fe32cb0977bed844e43bd8b3706dd03865..3d5b78c0df7e5615300acf73d8ee5e177aa47b91 100644 (file)
--- a/docs/docs/configuration/postgresql.md
+++ b/docs/docs/configuration/postgresql.md
@@ -6,29 +6,13 @@ Akkoma performance is largely dependent on performance of the underlying databas
 
 [PgTune](https://pgtune.leopard.in.ua) can be used to get recommended settings. Be sure to set "Number of Connections" to 20, otherwise it might produce settings hurtful to database performance. It is also recommended to not use "Network Storage" option.
 
-## Disable generic query plans
-
-When PostgreSQL receives a query, it decides on a strategy for searching the requested data, this is called a query plan. The query planner has two modes: generic and custom. Generic makes a plan for all queries of the same shape, ignoring the parameters, which is then cached and reused. Custom, on the contrary, generates a unique query plan based on query parameters.
-
-By default PostgreSQL has an algorithm to decide which mode is more efficient for particular query, however this algorithm has been observed to be wrong on some of the queries Akkoma sends, leading to serious performance loss. Therefore, it is recommended to disable generic mode.
-
-
-Akkoma already avoids generic query plans by default, however the method it uses is not the most efficient because it needs to be compatible with all supported PostgreSQL versions. For PostgreSQL 12 and higher additional performance can be gained by adding the following to Akkoma configuration:
-```elixir
-config :pleroma, Pleroma.Repo,
-  prepare: :named,
-  parameters: [
-    plan_cache_mode: "force_custom_plan"
-  ]
-```
-
-A more detailed explaination of the issue can be found at <https://blog.soykaf.com/post/postgresql-elixir-troubles/>.
+If your server runs other services, you may want to take that into account. E.g. if you have 4G ram, but 1G of it is already used for other services, it may be better to tell PGTune you only have 3G. In the end, PGTune only provides recomended settings, you can always try to finetune further.
 
-## Example configurations
+### Example configurations
 
 Here are some configuration suggestions for PostgreSQL 10+.
 
-### 1GB RAM, 1 CPU
+#### 1GB RAM, 1 CPU
 ```
 shared_buffers = 256MB
 effective_cache_size = 768MB
@@ -36,7 +20,7 @@ maintenance_work_mem = 64MB
 work_mem = 13107kB
 ```
 
-### 2GB RAM, 2 CPU
+#### 2GB RAM, 2 CPU
 ```
 shared_buffers = 512MB
 effective_cache_size = 1536MB
@@ -46,3 +30,21 @@ max_worker_processes = 2
 max_parallel_workers_per_gather = 1
 max_parallel_workers = 2
 ```
+
+## Disable generic query plans
+
+When PostgreSQL receives a query, it decides on a strategy for searching the requested data, this is called a query plan. The query planner has two modes: generic and custom. Generic makes a plan for all queries of the same shape, ignoring the parameters, which is then cached and reused. Custom, on the contrary, generates a unique query plan based on query parameters.
+
+By default PostgreSQL has an algorithm to decide which mode is more efficient for particular query, however this algorithm has been observed to be wrong on some of the queries Akkoma sends, leading to serious performance loss. Therefore, it is recommended to disable generic mode.
+
+
+Akkoma already avoids generic query plans by default, however the method it uses is not the most efficient because it needs to be compatible with all supported PostgreSQL versions. For PostgreSQL 12 and higher additional performance can be gained by adding the following to Akkoma configuration:
+```elixir
+config :pleroma, Pleroma.Repo,
+  prepare: :named,
+  parameters: [
+    plan_cache_mode: "force_custom_plan"
+  ]
+```
+
+A more detailed explaination of the issue can be found at <https://blog.soykaf.com/post/postgresql-elixir-troubles/>.