PostgreSQL Tuning LP Refresh

- Refresh PostgreSQL tuning guidance with measurement-driven Arm Neoverse framing
- Add an updated HammerDB TPROC-C normalized before-and-after image and alt text
- Expand kernel, huge page, 64 KB page, storage, and writeback guidance
- Clarify shared memory, WAL, planner, I/O, and concurrency tuning trade-offs
- Document durable synchronous_commit=on behavior and the loss-tolerant off option
- Remove unrelated prepared-transaction guidance and AWS-specific examples
- Modernize HammerDB TPROC-C setup and rename build and test scripts
- Update metadata, documentation links, transitions, and completion estimate

Author: jsrz

content/learning-paths/servers-and-cloud-computing/postgresql_tune/_index.md

@@ -1,15 +1,19 @@
 ---
-title: Learn how to Tune PostgreSQL
+title: Tune PostgreSQL performance on Arm-based platforms
+description: Learn how to tune PostgreSQL configuration, Linux memory settings, and storage options to improve database performance on Arm-based platforms.
 
-minutes_to_complete: 30
+minutes_to_complete: 150
 
-who_is_this_for: This is an advanced topic for software developers and DevOps professionals interested in optimizing PostgreSQL performance.
+who_is_this_for: This Learning Path is for database administrators (DBAs) and software developers who want to optimize PostgreSQL performance on Arm-based platforms.
 
 learning_objectives:
-    - Tune PostgreSQL to increase performance
+    - Configure PostgreSQL settings that affect connection handling, memory use, write-ahead logging, query planning, and concurrency.
+    - Enable huge pages for PostgreSQL and size them for the shared memory area.
+    - Evaluate storage, kernel, compiler, and library choices that can affect PostgreSQL performance.
 
 prerequisites:
-    - Bare-metal or cloud [installation of PostgreSQL](/learning-paths/servers-and-cloud-computing/postgresql/)
+    - On-prem or cloud [installation of PostgreSQL](/learning-paths/servers-and-cloud-computing/postgresql/)
+    - A repeatable PostgreSQL workload or benchmark that you can run before and after tuning
 
 author: Julio Suarez
 
@@ -42,17 +46,28 @@ tools_software_languages:
 further_reading:
     - resource:
         title: PostgreSQL documentation
-        link: https://www.postgresql.org/
+        link: https://www.postgresql.org/docs/current/
         type: documentation
     - resource:
-        title: "PostgreSQL on ARM: default page size matters"
-        link: https://dev.to/aws-heroes/postgresql-on-arm-default-page-size-matters-2n7a
-        type: blog
+        title: PostgreSQL resource consumption settings
+        link: https://www.postgresql.org/docs/current/runtime-config-resource.html
+        type: documentation
+    - resource:
+        title: PostgreSQL write-ahead log settings
+        link: https://www.postgresql.org/docs/current/runtime-config-wal.html
+        type: documentation
+    - resource:
+        title: Linux HugeTLBpage documentation
+        link: https://docs.kernel.org/admin-guide/mm/hugetlbpage.html
+        type: documentation
+    - resource:
+        title: Migrating applications to Arm servers
+        link: /learning-paths/servers-and-cloud-computing/migration/
+        type: learning-path
 
 ### FIXED, DO NOT MODIFY
 # ================================================================================
 weight: 1                       # _index.md always has weight of 1 to order correctly
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
-

content/learning-paths/servers-and-cloud-computing/postgresql_tune/before_and_after.md

@@ -1,17 +1,34 @@
 ---
-title: "Before and after tuning PostgreSQL"
+title: "Measure the impact of tuning PostgreSQL"
+description: Learn how to approach PostgreSQL performance tuning as a measurement-driven process and compare baseline results with tuned results.
 weight: 2
 layout: "learningpathall"
 ---
 
-##  About database performance tuning
+## About performance tuning
 
-Deployment configurations and the profile of SQL requests made by clients will differ based on the use case. This means there is no one size fits all set of tuning parameters for `PostgreSQL`.  Use the information in this learning path as guidance to help you tune `PostgreSQL` for your use case. Make sure to test any changes made to tuning parameters.
+Performance tuning is most useful when you treat it as a measurement process, not a fixed checklist. You can tune by changing one parameter at a time, running a designed experiment, comparing profiles, or using automation and AI-assisted tools to explore a larger configuration space.
 
-##  Importance of tuning
+There isn't a universal set of tuning parameters that works best for every PostgreSQL deployment. The right settings depend on the workload, data size, memory capacity, storage performance, network behavior, PostgreSQL version, system architecture, operating system, and other application-specific factors.
 
-Application tuning allows you to gain performance without scaling your deployment up (bigger machines) or out (more machines). You have the option to use the gained performance or trade it for cost savings by reducing the total compute resources provisioned. Below is a graph that shows the difference performance tuning on `PostgreSQL` can make.
+Whatever method you use, keep the measurements repeatable. Record the system configuration, workload, software versions, and tuning parameters so you can identify which changes improved performance and which changes had little effect.
 
-![Before and after Tuning](beforeandafter.png)
+## Why tune PostgreSQL
 
-Requirements vary based on the use case. In the example shown above, the AWS c7g.8xlarge instance could be down sized to a c7g.4xlarge to gain cost savings.
+PostgreSQL performance can be limited by memory use, storage I/O, connection handling, write-ahead logging, concurrency, or synchronization overhead. By tuning PostgreSQL, you can use the available compute, memory, and storage resources more efficiently.
+
+Improved performance can give you higher throughput, lower latency, or better cost efficiency. A tuned configuration can increase capacity on the same system or help you meet the same performance target with fewer compute resources.
+
+## Example benchmark result
+
+The following example shows PostgreSQL throughput with HammerDB TPROC-C before and after tuning on an Arm Neoverse V3 system. The throughput metric, NOPM, stands for New Orders Per Minute. The bars show normalized NOPM, with the out-of-box configuration set to `1.00`.
+
+![Bar chart comparing PostgreSQL HammerDB TPROC-C normalized NOPM throughput before and after tuning on an Arm Neoverse V3 system. At 128 clients, the out-of-box configuration is 1.00 and the tuned configuration is 4.43.#center](beforeandafter.png "PostgreSQL HammerDB TPROC-C throughput before and after tuning")
+
+This benchmark result is an example, not a guaranteed improvement for every workload. Your results depend on the PostgreSQL version, database size, storage device, memory capacity, client concurrency, and SQL statements used in the test. Record those details with your own results so you can interpret and reproduce the comparison.
+
+## What you've learned and what's next
+
+You've learned why PostgreSQL tuning benefits from a measurement-driven approach and reviewed an example of throughput improvement after tuning.
+
+Next, you'll examine the system-level settings that can affect PostgreSQL performance.