PostgreSQL Performance Problems: Monitoring and Alerting

PostgreSQL Performance
Problems:
Monitoring and Alerting

Grant Fritchey
DevOps Advocate
Microsoft Data Platform MVP
AWS Community Builder
About me
grant@scarydba.com
scarydba.com
@gfritchey
linkedin.com/in/grant-fritchey

Ryan Booz
PostgreSQL & DevOps
Advocate
@ryanbooz
About me
/in/ryanbooz
www.softwareandbooz.com
youtube.com/@ryanbooz

• Understand common
performance problems and how
to spot them
• Develop knowledge about the
tools within PostgreSQL that
show performance issues
• Learn about open source and 3rd
party monitoring solutions
Goals

Most Common Database
Problems
• Performance
• Scalability
• Security
• Multiple platforms
• Data integration & integrity
• Compliance

Today’s Focus, Performance Tuning

#PASSDataCommunitySummit
Easy Performance
Tuning

Actual Performance Tuning
Identify Poorly
Performing
Queries
Examine Code
and Execution
Plans
Implement
Potential Solution
Validate
Improvement
Deploy To
Production

Standard Tools For Performance Metrics

Statistics Views
• There are many. Each release tends to add more,
or more detail
• Most standard views ship with multiple versions:
• "all" view – contains a row for all objects of that type
• "sys" view – contains a row only for system objects of that type
• "user" view – contains a row only for user objects of that type

Standard Go-to Statistics Views
General
• pg_stat_database
• pg_stat_(all/sys/user)_tables
• pg_stat_(all/sys/user)_indexes
• pg_stat_io (PostgreSQL 16+)
For replication
• pg_stat_replication
• pg_stat_replication_slots
• pg_stat_subscription
• pg_stat_bgwriter
• pg_stat_archiver
• pg_stat_wal

pg_stat_database
• High-level statistics about each database
• Transaction counts
• Blocks used from cache or disk
• Tuples (rows) inserted, updated, deleted, etc.
• Deadlocks
• Session stats
• And more!

pg_stat_*_tables
• Some similarity to database statistics, but at the table level
• Tuple inserts, updates, deletes, hot updates, live, dead, etc.
• Time of last:
• table scan
• seq scan
• vacuum/autovacuum
• analyze/autoanalyzer
• And more!

PostgreSQL Performance Problems: Monitoring and Alerting

pg_stat_*_indexes
• Number of scans
• Last scan of index
• Tuples read or fetched using the index scan

pg_stat_io
• New in PostgreSQL 16
• Part of the 'contrib' modules
• I/O related statistics based on backend type, object type,
and context
• Helpful for tuning
• 'shared_buffers' (page cache)
• Checkpointer inefficiency
• Issues with background jobs

What is pg_stat_statements?
• An extension included with PostgreSQL 8.4+
• It is part of the contrib module but not enabled by default
• Must be loaded via ‘shared_preload_libraries’ in postgresql.conf
• Tracks aggregated statistics of all queries in the cluster
• Installing the extension in the database creates the necessary views to query the data

• Every dbid, userid, and
queryid
• Stats are grouped based on
query structure and final ID as
determined by an internal
hash calculation
How does it store aggregates?

How does it identify queries?
SELECT id, name FROM table1 WHERE id = 1000;
SELECT id, name FROM table1 WHERE id = $1;
SELECT id, name FROM table1 WHERE id IN
(1000,2000,3000);
SELECT id, name FROM table1 WHERE id IN
($1,$2,$3);

pg_stat_statement statistics
• Execution Time (total/min/max/mean/stddev)
• Planning Time (total/min/max/mean/stddev)
• Calls (total)
• Rows (total)
• Buffers (shared/local/temp)
• read/hit/dirtied/written
• read/write time
• WAL

39 Columns of data
(as of PG16)

All statistics are cumulative
from the last restart*
*or reset by a superuser

Caveats
• PostgreSQL 13
• modified column names to include
planning statistics
• PostgreSQL 14
• Must set “compute_query_id”=true
in postgresql.conf
• Includes informational view for
allocation and “last reset”
information

pg_stat_io
• New in PostgreSQL 16
• Part of the 'contrib' modules
• I/O related statistics based on backend type, object
type, and context
• Helpful for tuning
• 'shared_buffers' (page cache)
• Checkpointer inefficiency
• Issues with background jobs

pg_stat_kcache
• Open-source extension that provides statistics about real
reads and writes done at the filesystem layer
• Requires pg_stat_statements to be installed
• Must be added to the 'shared_preload_libraries' configuration
parameter
• Query-level filesystem statistics
• *Not often available in hosted environments

• AWS/Azure/GCP
have some limited
tooling to
track/display some
of this data
Postgres Tools for Data Collection

Common Tools
• pgAdmin and other IDEs
• Numerous open-source, Grafana-based tools
• pgWatch
• pgDash
• pg_stat_monitor
• auto_explain
• Some recent Python-based solutions, but they
aren't dynamic

Pros/cons
• Native tools, where available, are used by many, well
documented, and usually easy to get started with (at
least SQL Server)
• However, they can only go as far as the tool allows, and
they rarely have exactly the right documentation to
understand how to act upon the data
• Not all of these tools help you bring correlation between
the graphs and issues.
• Things are (at least slightly) desperate.

• Statistics determine plan choice
• Customizable per server, table, and column
• Asynchronous process maintains statistics
• Manually update with ANALYZE
Cost-based Optimizer

• Histogram of column values
• Defaults to 100 buckets
• Helpful views:
• pg_catalog.pg_stats
• pg_catalog.pg_stat_user_tables
Statistics

• EXPLAIN = Estimated plan
• EXPLAIN ANALYZE = Actual plan
• EXPLAIN (ANALYZE,BUFFERS)
• Query plan with disk IO
• EXPLAIN (ANALYZE,BUFFERS,VERBOSE)
• Additional details on columns, schemas, etc.
EXPLAIN in Practice

• Inverted tree representation
• There is no built-in visual execution plan
• EXPLAIN provides textual plan
• pgAdmin does attempt some visualizations
• Websites for visualizations and suggestions
• https://www.pgmustard.com/
• https://explain.depesz.com/
EXPLAIN

--> Nodes
Read inside-out
Join/Aggregate/Merge/Append at each level
EXPLAIN

EXPLAIN (ANALYZE, BUFFERS)
SELECT customer_name, count(*), date_part('year',order_date)::int order_year
FROM sales.orders o
INNER JOIN sales.customers c ON o.customer_id=c.customer_id
WHERE c.customer_id=100
GROUP BY customer_name,order_year
ORDER BY order_year DESC;
GroupAggregate (cost=1827.91..1830.76 rows=102 width=35) (actual time=11.956..13.754 rows=4 loops=1)
Group Key: ((date_part('year'::text, (o.order_date)::timestamp without time zone))::integer), c.customer_name
Buffers: shared hit=903
-> Sort (cost=1827.91..1828.18 rows=107 width=27) (actual time=11.700..12.686 rows=107 loops=1)
Sort Key: ((date_part('year'::text, (o.order_date)::timestamp without time zone))::integer) DESC, c.customer_name
Sort Method: quicksort Memory: 33kB
-> Nested Loop (cost=0.28..1824.30 rows=107 width=27) (actual time=0.113..10.649 rows=107 loops=1)
-> Index Scan using pk_sales_customers on customers c (cost=0.28..2.49 rows=1 width=27)
Index Cond: (customer_id = 100)
-> Seq Scan on orders o (cost=0.00..1819.94 rows=107 width=8) (actual time=0.053..8.413 rows=107 loops=1)
Filter: (customer_id = 100)
Rows Removed by Filter: 73488
Planning Time: 0.267 ms
Execution Time: 13.934 ms

GroupAggregate (cost=1827.91..1830.76 rows=102 width=35)
(actual time=11.956..13.754 rows=4 loops=1)
Group Key: ((date_part('year'::text, (o.order_date)::timestamp without time zone))::integer), c.customer_name
-> Sort (cost=1827.91..1828.18 rows=107 width=27) (actual time=11.700..12.686 rows=107 loops=1)
Sort Key: ((date_part('year'::text, (o.order_date)::timestamp without time zone))::integer) DESC, c.customer_name
Sort Method: quicksort Memory: 33kB
-> Nested Loop (cost=0.28..1824.30 rows=107 width=27) (actual time=0.113..10.649 rows=107 loops=1)
-> Index Scan using pk_sales_customers on customers c (cost=0.28..2.49 rows=1 width=27)
Index Cond: (customer_id = 100)
-> Seq Scan on orders o (cost=0.00..1819.94 rows=107 width=8) (actual time=0.053..8.413 rows=107 loops=1)
Filter: (customer_id = 100)
Rows Removed by Filter: 73488
Planning Time: 0.267 ms
Execution Time: 13.934 ms

• Sequence scan (seq scan)
• Index scan
• Index-only scan
Primary Scan nodes

• Nested Loop
• Hash Join
• Merge Join
Primary join nodes
Explain Glossary: https://www.pgmustard.com/docs/explain

Open Source Monitoring Solutions
Nagios
Core
PgHero pgCluu
pgWatch pgAdmin

Paid Monitoring Solutions
DataDog Better
Stack
pgDash
pgAnalyze Redgate
SQL
Monitor

• Understand the common
performance problems and how
to spot them
• Develop knowledge about the
tools within PostgreSQL that
show performance issues
• Learn about open source and 3rd
party monitoring solutions
Goals

PostgreSQL Performance Problems: Monitoring and Alerting

More Related Content

What's hot (20)

Similar to PostgreSQL Performance Problems: Monitoring and Alerting (20)

More from Grant Fritchey (20)

Recently uploaded (20)

PostgreSQL Performance Problems: Monitoring and Alerting

Editor's Notes