หา Missing Indexes -- Tables ที่มี sequential scan มาก (ควรมี index) SELECT schemaname, relname, seq_scan, seq_tup_read, idx_scan, idx_tup_fetch, n_tup_ins, n_tup_upd, n_tup_del, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_stat_user_tables WHERE seq_scan > 1000 AND seq_tup_read > 100000 AND idx_scan หา Unused Indexes (ลบได้) -- Indexes ที่ไม่เคยถูกใช้ (กิน disk + ช้า write) SELECT schemaname, tablename, indexname, idx_scan, pg_size_pretty(pg_relation_size(indexrelid)) AS index_size FROM pg_stat_user_indexes WHERE idx_scan = 0 AND indexrelid NOT IN ( SELECT conindid FROM pg_constraint WHERE contype IN ('p', 'u') -- ไม่ลบ PK/Unique ) ORDER BY pg_relation_size(indexrelid) DESC; Partial Index — ประหยัด disk + เร็วขึ้น -- แทนที่จะ index ทั้ง table CREATE INDEX idx_orders_status ON orders(status); -- 100 ล้าน rows, index size: 2GB -- ใช้ partial index เฉพาะ rows ที่ query บ่อย CREATE INDEX idx_orders_pending ON orders(created_at) WHERE status = 'pending'; -- เฉพาะ pending orders (1% ของ table), index size: 20MB -- เร็วกว่า 100 เท่า! Covering Index (INCLUDE) -- Query นี้ต้อง lookup table หลัง scan index SELECT email, name FROM users WHERE email = 'john@example.com'; -- Covering index — ไม่ต้อง lookup table (index-only scan) CREATE INDEX idx_users_email_covering ON users(email) INCLUDE (name); -- เร็วขึ้น 2-5 เท่า สำหรับ query ที่ SELECT แค่ columns ที่อยู่ใน index EXPLAIN ANALYZE — อ่าน Query Plan EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) SELECT o.id, o.total, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'pending' AND o.created_at > NOW() - INTERVAL '7 days' ORDER BY o.created_at DESC LIMIT 50; -- Output: -- Limit (cost=0.87..125.43 rows=50 width=52) (actual time=0.089..0.234 rows=50 loops=1) -- Buffers: shared hit=156 -- -> Nested Loop (cost=0.87..12543.21 rows=5021 width=52) (actual time=0.088..0.228 rows=50 loops=1) -- -> Index Scan Backward using idx_orders_pending on orders o -- (cost=0.43..8234.12 rows=5021 width=36) (actual time=0.052..0.089 rows=50 loops=1) -- Filter: (created_at > (now() - '7 days'::interval)) -- Buffers: shared hit=53 -- -> Index Scan using users_pkey on users u -- (cost=0.43..0.86 rows=1 width=20) (actual time=0.002..0.002 rows=1 loops=50) -- Index Cond: (id = o.user_id) -- Buffers: shared hit=103 -- Planning Time: 0.312 ms -- Execution Time: 0.267 ms สิ่งที่ต้องดู: Seq Scan บน table ใหญ่ = ต้องสร้าง index Buffers: shared hit = อ่านจาก cache (ดี) vs shared read = อ่านจาก disk (ช้า) actual time vs cost — ถ้าต่างกันมาก = statistics ไม่ update ให้รัน ANALYZE rows (estimated) vs rows (actual) — ถ้าต่างกันมาก = planner เลือก plan ผิด pg_stat_statements — หา Slow Queries -- เปิด pg_stat_statements -- postgresql.conf: -- shared_preload_libraries = 'pg_stat_statements' -- pg_stat_statements.track = all CREATE EXTENSION IF NOT EXISTS pg_stat_statements; -- Top 20 queries ที่ใช้เวลารวมมากที่สุด SELECT substring(query, 1, 100) AS query, calls, round(total_exec_time::numeric, 2) AS total_ms, round(mean_exec_time::numeric, 2) AS avg_ms, round((100 * total_exec_time / sum(total_exec_time) OVER ())::numeric, 2) AS pct, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; -- Top queries ที่ช้าที่สุด (per call) SELECT substring(query, 1, 100) AS query, calls, round(mean_exec_time::numeric, 2) AS avg_ms, round(max_exec_time::numeric, 2) AS max_ms FROM pg_stat_statements WHERE calls > 100 ORDER BY mean_exec_time DESC LIMIT 20; Table Partitioning -- สร้าง partitioned table (by range) CREATE TABLE orders ( id BIGSERIAL, user_id BIGINT NOT NULL, total DECIMAL(10,2) NOT NULL, status VARCHAR(20) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ) PARTITION BY RANGE (created_at); -- สร้าง partitions รายเดือน CREATE TABLE orders_2026_01 PARTITION OF orders FOR VALUES FROM ('2026-01-01') TO ('2026-02-01'); CREATE TABLE orders_2026_02 PARTITION OF orders FOR VALUES FROM ('2026-02-01') TO ('2026-03-01'); CREATE TABLE orders_2026_03 PARTITION OF orders FOR VALUES FROM ('2026-03-01') TO ('2026-04-01'); -- Auto-create partitions ด้วย pg_partman CREATE EXTENSION pg_partman; SELECT partman.create_parent( p_parent_table := 'public.orders', p_control := 'created_at', p_type := 'native', p_interval := '1 month', p_premake := 3 ); ผลลัพธ์: table 500 ล้าน rows → query ที่ filter by date เร็วขึ้น 50-100 เท่า เพราะ PostgreSQL scan แค่ partition ที่เกี่ยวข้อง ไม่ต้อง scan ทั้ง table Backup Strategy # Continuous Archiving + PITR (Point-in-Time Recovery) # postgresql.conf: archive_mode = on archive_command = 'aws s3 cp %p s3://my-pg-backups/wal/%f' # Base backup ทุกวัน pg_basebackup -h localhost -U replicator -D /backup/base \ --wal-method=stream --checkpoint=fast --progress # Restore to specific point in time restore_command = 'aws s3 cp s3://my-pg-backups/wal/%f %p' recovery_target_time = '2026-02-17 08:00:00+07' 📌 บทความแนะนำจาก siamlancard: Order Block | Price Action | Candlestick Pattern Troubleshooting ปัญหา 1: Lock contention -- หา queries ที่ถูก block SELECT blocked.pid AS blocked_pid, blocked.query AS blocked_query, blocking.pid AS blocking_pid, blocking.query AS blocking_query, now() - blocked.query_start AS blocked_duration FROM pg_stat_activity blocked JOIN pg_locks bl ON bl.pid = blocked.pid JOIN pg_locks bk ON bk.locktype = bl.locktype AND bk.database IS NOT DISTINCT FROM bl.database AND bk.relation IS NOT DISTINCT FROM bl.relation AND bk.page IS NOT DISTINCT FROM bl.page AND bk.tuple IS NOT DISTINCT FROM bl.tuple AND bk.pid != bl.pid JOIN pg_stat_activity blocking ON bk.pid = blocking.pid WHERE NOT bl.granted; ปัญหา 2: Table bloat -- ตรวจสอบ bloat SELECT schemaname, tablename, pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size, n_dead_tup, n_live_tup, round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 2) AS dead_pct FROM pg_stat_user_tables WHERE n_dead_tup > 10000 ORDER BY n_dead_tup DESC; -- แก้: VACUUM FULL (ล็อค table!) หรือ pg_repack (online) -- pg_repack ดีกว่าเพราะไม่ lock table pg_repack -d mydb -t bloated_table ปัญหา 3: Connection exhaustion -- ดู connections ปัจจุบัน SELECT state, count(*) FROM pg_stat_activity GROUP BY state; -- Kill idle connections ที่ค้างนาน SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND query_start คำถามที่พบบ่อย (FAQ) Q: shared_buffers ตั้งเท่าไหร่ดี?

A: 25% ของ RAM เป็นจุดเริ่มต้นที่ดี ไม่เกิน 8GB บน Linux เพราะ OS file cache ทำงานร่วมกับ PostgreSQL ได้ดี

Q: work_mem ตั้งสูงๆ ได้ไหม?

A: ระวัง! work_mem เป็น per-operation ถ้าตั้ง 1GB และมี 100 connections ที่รัน complex query พร้อมกัน อาจใช้ RAM 100GB+ ทำให้ OOM kill

Q: PostgreSQL กับ MySQL เลือกอะไรดี?

A: PostgreSQL ดีกว่าสำหรับ complex queries, JSON, full-text search, geospatial MySQL ดีกว่าสำหรับ simple read-heavy workloads ที่ต้องการ replication ง่ายๆ

Q: ควรใช้ managed service (RDS, Cloud SQL) ไหม?

A: ถ้าทีมเล็ก (1-3 DBAs) ใช้ managed service ดีกว่า ประหยัดเวลา ops ถ้าต้องการ control เต็มที่หรือ cost-sensitive ใช้ self-managed

Q: VACUUM FULL กับ VACUUM ต่างกันอย่างไร?

A: VACUUM ปกติ mark dead tuples ให้ reuse ได้ ไม่ lock table VACUUM FULL rewrite table ใหม่ทั้งหมด ลดขนาดจริง แต่ lock table ตลอดเวลาที่ทำ ใช้ pg_repack แทน VACUUM FULL

PostgreSQL Performance Tuning Production

PostgreSQL Performance Tuning คืออะไร?

PostgreSQL เป็น database ที่ทรงพลังที่สุดในโลก open-source แต่ default config ถูกตั้งมาให้ทำงานบนเครื่องที่มี RAM แค่ 1-2 GB ดังนั้น ถ้าใช้ PostgreSQL ใน production โดยไม่ tune ก็เหมือนขับ Ferrari ด้วยเกียร์ 1 ตลอดทาง

บทความนี้จะสอนวิธี tune PostgreSQL ให้เร็วขึ้น 5-20 เท่าสำหรับ server ที่มี RAM 16 GB ขึ้นไป

postgresql.conf — ค่าสำคัญที่ต้อง Tune

Parameter	Default	แนะนำ (RAM 32GB)	คำอธิบาย
shared_buffers	128 MB	8 GB (25% RAM)	Buffer pool สำหรับ cache data pages
effective_cache_size	4 GB	24 GB (75% RAM)	บอก planner ว่ามี cache เท่าไหร่
work_mem	4 MB	64-256 MB	Memory per sort/hash operation
maintenance_work_mem	64 MB	2 GB	Memory สำหรับ VACUUM, CREATE INDEX
max_connections	100	200	ใช้ PgBouncer แทนการเพิ่ม
wal_buffers	-1	64 MB	Buffer สำหรับ WAL writes
random_page_cost	4.0	1.1	ลดลงถ้าใช้ SSD (สำคัญมาก!)
effective_io_concurrency	1	200	เพิ่มสำหรับ SSD/NVMe

ตัวอย่าง Config สำหรับ Server RAM 32 GB

# /etc/postgresql/16/main/postgresql.conf

# Memory
shared_buffers = '8GB'
effective_cache_size = '24GB'
work_mem = '128MB'
maintenance_work_mem = '2GB'
wal_buffers = '64MB'

# Disk / SSD optimization
random_page_cost = 1.1
effective_io_concurrency = 200
max_parallel_workers_per_gather = 4
max_parallel_workers = 8

# WAL / Checkpoints
wal_level = replica
max_wal_size = '4GB'
min_wal_size = '1GB'
checkpoint_completion_target = 0.9

# Connections (ใช้ PgBouncer แทน)
max_connections = 200

# Logging
log_min_duration_statement = 500 # log queries ที่นานกว่า 500ms
log_checkpoints = on
log_lock_waits = on

Index Optimization — หัวใจของ Performance

Index ที่ดีทำให้ query เร็วขึ้น 100-1000 เท่าข้อแนะนำ:

ดู slow queries ก่อน — เปิด pg_stat_statements extension แล้วดู query ที่ช้าที่สุด
ใช้ EXPLAIN ANALYZE — EXPLAIN (ANALYZE, BUFFERS) SELECT ... ดูว่า query ใช้ Seq Scan หรือ Index Scan
สร้าง Partial Index — CREATE INDEX ON orders (status) WHERE status = 'pending' ถ้า query filter ค่าเดิมซ้ำๆ
ใช้ Covering Index — CREATE INDEX ON users (email) INCLUDE (name, role) ลด table lookup
หา Missing Indexes — ดูจาก pg_stat_user_tables ถ้า seq_scan สูงมากแสดงว่าขาด index

Connection Pooling ด้วย PgBouncer

PostgreSQL สร้าง process ใหม่ทุก connection ใช้ RAM ~10 MB ต่อ connection ถ้ามี 500 connections = 5 GB RAM เฉพาะ connections PgBouncer แก้ปัญหานี้โดย pool connections ให้ reuse

# /etc/pgbouncer/pgbouncer.ini
[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
pool_mode = transaction # แนะนำ transaction mode
max_client_conn = 1000
default_pool_size = 50
min_pool_size = 10

ผลลัพธ์: app เชื่อมต่อ PgBouncer port 6432 แทน PostgreSQL port 5432 โดย PgBouncer จะ pool 1000 client connections ผ่าน 50 PostgreSQL connections จริงลด memory usage ได้มหาศาล

VACUUM และ Maintenance

PostgreSQL ใช้ MVCC ที่สร้าง dead tuples ทุกครั้งที่ UPDATE/DELETE ถ้าไม่ VACUUM ตารางจะบวมขึ้นเรื่อยๆ:

autovacuum — เปิดเสมอ (default on) อย่าปิด
ตั้ง autovacuum ให้ aggressive ขึ้น สำหรับตารางที่ update บ่อย
pg_repack — ใช้ repack table ที่บวมมากโดยไม่ต้อง lock table
ตรวจสอบ bloat — SELECT relname, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;

Q: PostgreSQL vs MySQL ใน production ตัวไหนดีกว่า?

ขึ้นอยู่กับ use case ครับ PostgreSQL ดีกว่าสำหรับ complex queries, JSON, geospatial, full-text search และ data integrity MySQL ดีกว่าสำหรับ simple read-heavy workloads และ replication ง่ายกว่าในปี 2026 PostgreSQL ได้รับความนิยมมากกว่าแล้ว

PostgreSQL Performance Tuning Production คู่มือสมบูรณ์ 2026

PostgreSQL Performance Tuning คืออะไร?

postgresql.conf — ค่าสำคัญที่ต้อง Tune

ตัวอย่าง Config สำหรับ Server RAM 32 GB

Index Optimization — หัวใจของ Performance

Connection Pooling ด้วย PgBouncer

VACUUM และ Maintenance

Q: PostgreSQL vs MySQL ใน production ตัวไหนดีกว่า?

Q: ใช้ PgBouncer หรือ Pgpool-II ดี?

PostgreSQL Monitoring และ Troubleshooting

PostgreSQL สำหรับธุรกิจไทยในปี 2026

เจาะลึก PostgreSQL Performance Tuning Production คู่มือสมบูรณ์

วิธีเริ่มต้นใช้งาน PostgreSQL Performance Tuning Production คู่มือสมบูรณ์

ขั้นตอนที่ 1: การเตรียมความพร้อม

ขั้นตอนที่ 2: การติดตั้งและตั้งค่า

ขั้นตอนที่ 3: การทดสอบและปรับแต่ง

แนวทางปฏิบัติที่ดีที่สุดสำหรับ PostgreSQL Performance Tuning Production คู่มือสมบูรณ์

📖 บทความที่เกี่ยวข้อง

📰 บทความล่าสุด