Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -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

Expand Down Expand Up @@ -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.
---

Original file line number Diff line number Diff line change
@@ -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.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Loading