Skip to content

updating param desc#35

Merged
sebastianwebber merged 21 commits intomainfrom
seba/update-param-short-desc
Feb 5, 2026
Merged

updating param desc#35
sebastianwebber merged 21 commits intomainfrom
seba/update-param-short-desc

Conversation

@sebastianwebber
Copy link
Contributor

@sebastianwebber sebastianwebber commented Feb 4, 2026

Documentation Improvements (rules.yml)

Memory Parameters

  • shared_buffers: Updated guidance to start with 25% of RAM and use pg_buffercache extension for optimal tuning based on workload analysis
  • effective_cache_size: Clarified that it doesn't allocate memory, only informs planner. Added formula: RAM - shared_buffers
  • work_mem: Added critical OOM warnings with worst-case calculation example (work_mem × operations × parallel_workers × connections). Emphasized per-session tuning over global settings
  • maintenance_work_mem: Added PostgreSQL 17+ information about parallel CREATE INDEX improvements and version-specific optimizations

Write-Ahead Log (WAL) Parameters

  • min_wal_size / max_wal_size: Enhanced with workload-specific recommendations and monitoring guidance
  • checkpoint_completion_target: Added practical example showing impact of spreading checkpoints
  • wal_buffers: Clarified auto-tuning behavior and when to set explicit values

Network Parameters

  • listen_addresses: Added security considerations and Docker/cloud environment guidance
  • max_connections: Added connection pooling recommendations (PgBouncer, pgpool-II) with trade-offs

Storage Parameters (PostgreSQL 18+)

  • effective_io_concurrency: Clarified it only affects bitmap heap scans, added PostgreSQL 18 default change (1→16)
  • maintenance_io_concurrency: Explained relationship with VACUUM, CREATE INDEX, ANALYZE operations
  • random_page_cost: Documented 2025 debate on SSD values, explained sequential vs index scan trade-offs
  • io_method: Detailed differences between worker, io_uring, and sync methods with platform-specific guidance
  • io_workers: Added workload-specific sizing guidance (10-40% of CPU cores)
  • io_combine_limit / io_max_combine_limit: Explained I/O batching benefits for sequential scans
  • io_max_concurrency: Documented read-ahead formula and memory pressure considerations
  • file_copy_method: Added recommendation for clone method on supported filesystems (Btrfs, XFS, APFS, ZFS)

Worker Parameters

  • max_worker_processes: Explained worker pool concept and consumers (parallel query, replication, extensions)
  • max_parallel_workers: Clarified system-wide limit and relationship with max_worker_processes
  • max_parallel_workers_per_gather: Documented resource multiplication effect (N workers = N+1x resources)

Code Optimizations

Checkpoint Tuning (checkpoint.go)

WAL Buffers Optimization:

  • DW (Data Warehouse): 64MB for write-heavy batch operations
  • OLTP with large shared_buffers (>8GB): 32MB for high concurrent writes
  • Other profiles: Auto-tuning (-1)

WAL Size Optimization per Profile:

  • DW: min=4GB, max=16GB (write-heavy with batch jobs)
  • OLTP: min=2GB, max=8GB (frequent transactions)
  • Web: min=1GB, max=4GB (moderate writes)
  • Mixed: min=2GB, max=6GB (balanced workload)
  • Desktop: min=512MB, max=2GB (low activity)

Storage Tuning (storage.go)

Random Page Cost Optimization:

  • DW profile with SSD/SAN: 1.8 (favors sequential scans for analytical queries touching >10% of rows)
  • Other profiles with SSD/SAN: 1.1 (favors index scans)
  • HDD: 4.0 (PostgreSQL default)

I/O Concurrency (by disk type):

  • SSD: 200 (effective_io_concurrency and maintenance_io_concurrency)
  • SAN: 300
  • HDD: 2

Async I/O Tuning (aio.go)

I/O Workers (by profile and disk type):

  • Base factors: Desktop 10%, Web 20%, Mixed 25%, OLTP 30%, DW 40%
  • HDD adds +10% (higher latency benefits from more workers)
  • Minimum 2 workers, capped at TotalCPU

I/O Max Combine Limit:

  • DW: 128 blocks (1MB) for large sequential scans
  • Other profiles: 16 blocks (128KB, default)

I/O Max Concurrency:

  • DW: 256 (high read-ahead for analytics)
  • OLTP: 128 (balanced concurrency)
  • Other profiles: 64 (default)

Worker Configuration (worker.go)

Dynamic Scaling with CPU Cores:

  • max_worker_processes: max(8, TotalCPU)
  • max_parallel_workers: max(8, TotalCPU)
  • max_parallel_workers_per_gather:
    • Desktop/Web/Mixed/OLTP: 2 (transactional workloads don't benefit from high parallelism)
    • DW: min(TotalCPU/2, max_parallel_workers) with minimum of 2 (analytical queries benefit from parallelism)

Testing

  • Added comprehensive table-driven tests for:
    • WAL configuration (TestComputeWalSizes, TestComputeWalBuffers)
    • Storage configuration (Test_computeStorageRandomPageCost)
    • Async I/O configuration (Test_computeAIO with 10 test cases)
    • Worker configuration (TestNewWorkerCfg with 9 test cases covering various CPU counts and profiles)

References Added

All documentation updates include authoritative references from:

  • PostgreSQL official documentation
  • Cybertec PostgreSQL blog
  • Crunchy Data blog
  • pganalyze blog and tools
  • Percona blog
  • AWS, Neon, and other cloud provider resources
  • 2025 performance tuning guides

Key Design Principles

  1. Workload-Specific Optimization: Different configurations for OLTP vs DW workloads
  2. Hardware-Aware Scaling: Parameters scale with CPU cores and disk types
  3. Conservative Defaults: Maintain safe defaults while enabling performance for capable systems
  4. Modern Best Practices: Incorporate PostgreSQL 17-18 improvements and 2025 recommendations
  5. Resource Safety: Prevent memory exhaustion with appropriate limits and warnings

Clarify that 25% RAM is a starting point, not a strict rule.
Recommend using pg_buffercache extension for workload-specific
optimization. Add recent references for tuning methodology.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add references explaining PostgreSQL double buffering mechanism
and how shared_buffers works with OS page cache. Clarify that
effective_cache_size is for planner estimates only, with formula
for starting point calculation.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add explicit warning about potential OOM kills in Kubernetes and
cloud environments. Include worst-case calculation example showing
how work_mem can multiply to 102GB. Add references for temp file
monitoring and per-session tuning. Update recommendations with
2025 best practices and remove outdated 2011 reference.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add details about PostgreSQL version differences (1GB limit until
v16, radix trees in v17+). Include autovacuum_max_workers multiply
warning and reference to autovacuum_work_mem. Add AWS RDS autovacuum
guide and 2025 best practices.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify WAL recycling behavior and checkpoint triggering. Add
recommendation to set max_wal_size for 1 hour of WAL with monitoring
via pg_stat_bgwriter. Replace outdated 2016 reference with current
best practices from official docs, EDB, Cybertec, and Crunchy Data.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add practical calculation example showing how 0.9 spreads writes
over 4min 30s of a 5min interval. Include multiple monitoring
resources for pg_stat_bgwriter. Replace outdated 2010 reference
with current best practices and monitoring guides.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Set wal_buffers to 64MB for DW profile and 32MB for OLTP when
shared_buffers > 8GB. Research shows these values can double
performance for write-intensive systems vs auto-tune default.

Add comprehensive table-driven tests covering all profiles and
RAM sizes. Update documentation with profile-specific tuning
recommendations and current best practices.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add security warnings for listen_addresses emphasizing localhost
default and dangers of exposing to internet. Recommend specific
IPs with pg_hba.conf or SSH tunnels.

Expand max_connections guidance with connection pooling best
practices. Include memory formula and PgBouncer references for
high-concurrency scenarios.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Tune WAL sizes based on workload characteristics:
- DW (Data Warehouse): 4GB/16GB for write-heavy batch jobs
- OLTP: 2GB/8GB for frequent transactions
- Web: 1GB/4GB for moderate writes
- Mixed: 2GB/6GB for balanced workload
- Desktop: 512MB/2GB for low activity

Add comprehensive tests validating all profile configurations.
Aligns with best practice of holding ~1 hour of WAL for most
systems while accommodating different write patterns.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Set random_page_cost to 1.8 for DW profile on SSD/SAN storage,
as analytical queries often touch >10% of rows where sequential
scans are more efficient than index scans. Other profiles maintain
1.1 for SSD to favor index scans.

Add comprehensive table-driven tests covering all profile and
storage combinations. Update documentation with 2025 debate on
plan stability vs SSD optimization, and guidance on when
sequential scans become more efficient.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify that parameter only affects bitmap heap scans and add
context about when bitmap scans are used. Include note about
PostgreSQL 18 default change from 1 to 16.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify differences between worker, io_uring, and sync methods.
Add recommendations on when to use each option and note that
async I/O only affects reads in PostgreSQL 18.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add workload-specific recommendations for worker count based on
CPU cores (10-40%). Explain when higher values are beneficial and
how to monitor for saturation.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify that parameter applies to VACUUM, CREATE INDEX, and ANALYZE.
Add note about PostgreSQL 18 default change and relationship to
effective_io_concurrency. Include workload-specific tuning references.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify relationship between the two parameters and explain how
larger values benefit sequential scans. Add note about PostgreSQL 18
requirement and data warehouse use cases.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add read-ahead formula and explain relationship with other I/O
parameters. Note memory pressure concerns with high concurrency
and benefits for high-latency storage.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Add recommendation to use clone method when filesystem supports it.
Explain performance benefits (200-600ms for 100s of GB) and zero
initial disk space consumption with CoW filesystems.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Explain worker pool concept and various consumers (parallel query,
replication, extensions). Add recommendation to set based on CPU
core count or at least 25% of vCPUs.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Explain resource multiplication effect (N workers = N+1x resources).
Add references for parallel query tuning and analytics workload
optimization.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Clarify system-wide limit and relationship with max_worker_processes.
Add recommendation to set equal to CPU core count.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
Scale worker parameters with CPU cores instead of using fixed values:
- max_worker_processes: minimum 8 or CPU count
- max_parallel_workers: minimum 8 or CPU count
- max_parallel_workers_per_gather: 2 for transactional workloads
  (Desktop/Web/Mixed/OLTP), CPU/2 for DW (analytical workloads)

Add comprehensive table-driven tests covering various CPU counts
and workload profiles.

Signed-off-by: Sebastian Webber <sebastian@swebber.me>
@sebastianwebber sebastianwebber merged commit ea4bf01 into main Feb 5, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant