PostgreSQL Performance Tuning คู่มือปรับแต่งฐานข้อมูล

สวัสดีครับ นักพัฒนาและผู้ดูแลระบบทุกท่าน! ในโลกของแอปพลิเคชันยุคใหม่ที่ขับเคลื่อนด้วยข้อมูล ฐานข้อมูลเปรียบเสมือนหัวใจสำคัญที่หล่อเลี้ยงระบบทั้งหมดให้ทำงานได้อย่างราบรื่น และสำหรับฐานข้อมูลเชิงสัมพันธ์แล้ว PostgreSQL ถือเป็นหนึ่งในตัวเลือกที่ได้รับความนิยมอย่างสูง ด้วยความแข็งแกร่ง, ฟีเจอร์ที่ครบครัน, และความเป็นโอเพนซอร์สที่เปิดกว้าง แต่ไม่ว่าฐานข้อมูลจะดีแค่ไหน หากขาดการปรับแต่งที่เหมาะสม ประสิทธิภาพก็อาจไม่เป็นไปตามที่คาดหวังได้ โดยเฉพาะเมื่อปริมาณข้อมูลและจำนวนผู้ใช้งานเพิ่มขึ้นอย่างรวดเร็ว ปัญหาคอขวด (bottleneck) ก็อาจเกิดขึ้นได้ทุกเมื่อ

บทความนี้ SiamLancard.com ขอพาทุกท่านดำดิ่งสู่โลกของการ PostgreSQL Performance Tuning อย่างละเอียดและเจาะลึก ตั้งแต่หลักการพื้นฐานไปจนถึงเทคนิคขั้นสูง เราจะครอบคลุมทุกแง่มุมของการปรับแต่ง ไม่ว่าจะเป็นการปรับค่า Configuration ของเซิร์ฟเวอร์, การออกแบบ Index ที่มีประสิทธิภาพ, การเขียน SQL Query ให้รวดเร็ว, การจัดการ Autovacuum, ไปจนถึงการใช้เครื่องมือ Monitoring ต่างๆ เพื่อให้ท่านสามารถรีดศักยภาพสูงสุดจาก PostgreSQL ของท่านได้อย่างเต็มที่ พร้อมตัวอย่างโค้ดและคำอธิบายที่เข้าใจง่าย เพื่อให้ทุกท่านนำไปปรับใช้ได้จริงครับ

บทนำ: ทำไมต้องปรับแต่ง PostgreSQL?

PostgreSQL เป็นฐานข้อมูลที่ยอดเยี่ยม แต่การตั้งค่าเริ่มต้น (default configuration) มักถูกออกแบบมาให้ทำงานได้ดีในหลากหลายสภาพแวดล้อม ซึ่งหมายความว่ามันอาจไม่ได้ถูกปรับให้เหมาะสมกับเวิร์คโหลดเฉพาะของแอปพลิเคชันของคุณเสมอไปครับ การไม่ปรับแต่งที่เหมาะสมอาจนำไปสู่ปัญหาต่างๆ เช่น:

• ประสิทธิภาพการทำงานที่ช้าลง: Query ที่ใช้เวลานาน, Response Time ที่สูงขึ้น, แอปพลิเคชันที่รู้สึกหน่วง
• การใช้ทรัพยากรที่ไม่เหมาะสม: การใช้ CPU, RAM, หรือ Disk I/O มากเกินความจำเป็น หรือใช้ไม่เต็มประสิทธิภาพ
• ปัญหา Out-of-Memory: หากมีการตั้งค่า work_mem หรือ shared_buffers ไม่เหมาะสม
• ข้อมูลค้างและ Dead Tuples: ทำให้ขนาดฐานข้อมูลบวมขึ้นและ Query ช้าลง หาก Autovacuum ทำงานได้ไม่ดี
• ความไม่เสถียรของระบบ: Server อาจหยุดทำงานหรือเกิด Crash ได้ หากมีการตั้งค่าที่ผิดพลาด

การปรับแต่ง PostgreSQL ไม่ใช่แค่การเปลี่ยนตัวเลขในไฟล์ postgresql.conf เท่านั้น แต่เป็นการทำความเข้าใจว่าฐานข้อมูลทำงานอย่างไร, แอปพลิเคชันของคุณใช้งานฐานข้อมูลแบบไหน, และทรัพยากรของเซิร์ฟเวอร์ที่คุณมีอยู่เป็นอย่างไรครับ มันคือการเดินทางที่ต้องอาศัยทั้งความรู้, ประสบการณ์, และการทดลองอย่างรอบคอบ เพื่อให้ได้มาซึ่งประสิทธิภาพสูงสุดภายใต้ข้อจำกัดที่มีอยู่

ทำความเข้าใจสถาปัตยกรรม PostgreSQL สำหรับการปรับแต่ง

ก่อนที่เราจะเริ่มปรับแต่ง เราต้องเข้าใจโครงสร้างพื้นฐานและกลไกการทำงานของ PostgreSQL เสียก่อนครับ การเข้าใจส่วนประกอบหลักเหล่านี้จะช่วยให้เราตัดสินใจได้ดีขึ้นว่าจะปรับค่าพารามิเตอร์ใด และทำไมถึงต้องปรับค่าเหล่านั้นครับ

Shared Buffers

shared_buffers คือส่วนหนึ่งของหน่วยความจำ (RAM) ที่ PostgreSQL ใช้เก็บข้อมูล (data pages) ที่ถูกเรียกใช้บ่อยๆ จากดิสก์ครับ ยิ่งมีขนาดใหญ่เท่าไหร่ PostgreSQL ก็ยิ่งสามารถเก็บข้อมูลที่ใช้บ่อยไว้ใน RAM ได้มากขึ้น ทำให้ลดการอ่านจากดิสก์ซึ่งช้ากว่ามาก ส่งผลให้ Query ทำงานได้เร็วขึ้นอย่างเห็นได้ชัดครับ

Write-Ahead Log (WAL)

WAL เป็นกลไกสำคัญที่รับประกันความคงทนของข้อมูล (data durability) ครับ ก่อนที่การเปลี่ยนแปลงใดๆ จะถูกบันทึกลงไฟล์ข้อมูลหลักบนดิสก์ ข้อมูลการเปลี่ยนแปลงนั้นจะถูกเขียนลง WAL ก่อนเสมอ ซึ่ง WAL จะถูกเขียนแบบต่อเนื่อง (sequentially) ซึ่งเร็วกว่าการเขียนข้อมูลแบบสุ่ม (randomly) ครับ การตั้งค่าที่เกี่ยวข้องกับ WAL เช่น wal_buffers และ wal_writer_delay มีผลต่อประสิทธิภาพการเขียนข้อมูลอย่างมากครับ

Checkpoints

Checkpoint คือกระบวนการที่ PostgreSQL เขียนข้อมูลที่อยู่ใน shared_buffers (dirty pages) ลงดิสก์อย่างถาวรครับ และยังเป็นจุดที่ WAL เก่าๆ สามารถถูกลบออกไปได้ด้วย การเกิด Checkpoint บ่อยเกินไปหรือไม่บ่อยเกินไป ล้วนส่งผลกระทบต่อประสิทธิภาพการทำงานได้ทั้งสิ้นครับ เพราะมันจะสร้างภาระ I/O ที่สูงขึ้นในช่วงเวลานั้นๆ ครับ

Autovacuum

PostgreSQL ใช้สถาปัตยกรรมแบบ Multi-Version Concurrency Control (MVCC) ซึ่งหมายความว่าเมื่อมีการอัปเดตหรือลบข้อมูล แถวข้อมูลเก่าจะไม่ได้ถูกลบออกไปทันที แต่จะถูกทำเครื่องหมายว่าเป็น “dead tuple” แทนครับ Autovacuum คือกระบวนการเบื้องหลังที่คอยกวาดล้าง dead tuples เหล่านี้ และอัปเดตสถิติของตารางและ Index เพื่อให้ Query Planner สามารถเลือกแผนการทำงานที่ดีที่สุดได้ครับ หาก Autovacuum ทำงานได้ไม่ดี ฐานข้อมูลจะบวมขึ้นเรื่อยๆ และประสิทธิภาพจะลดลงอย่างมากครับ

Pre-Tuning Checklist: การเตรียมตัวก่อนเริ่มปรับแต่ง

การปรับแต่งประสิทธิภาพไม่ใช่การลองผิดลองถูกแบบสุ่มสี่สุ่มห้าครับ มันต้องมีขั้นตอนที่เป็นระบบ การเตรียมตัวที่ดีจะช่วยให้การปรับแต่งมีประสิทธิภาพและลดความเสี่ยงให้น้อยที่สุดครับ

เครื่องมือ Monitoring ที่จำเป็น

ก่อนอื่น เราต้องมีวิธีในการสังเกตการณ์และวัดผลการทำงานของฐานข้อมูลครับ

• pg_stat_activity: ดูว่ามี Query ใดกำลังรันอยู่บ้าง, สถานะเป็นอย่างไร, ใครเป็นคนรัน, และใช้เวลานานแค่ไหนครับ

  
  SELECT
      datname,
      pid,
      usename,
      client_addr,
      application_name,
      backend_start,
      state,
      query_start,
      waiting,
      query
  FROM
      pg_stat_activity
  WHERE
      state = 'active'
  ORDER BY
      query_start;
          

• pg_stat_statements: (ต้องเปิดใช้งานใน postgresql.conf) ใช้ติดตามสถิติของ Query ที่รันอยู่ทั้งหมด เช่น จำนวนครั้งที่รัน, เวลาเฉลี่ย, เวลาสูงสุด, และ I/O ที่ใช้ไปครับ เป็นเครื่องมือที่ทรงพลังมากในการหา Query ที่มีปัญหาครับ

  
  -- ต้องติดตั้ง extension pg_stat_statements ก่อน
  -- ใน postgresql.conf: shared_preload_libraries = 'pg_stat_statements'
  -- หลังจาก restart PG, รัน: CREATE EXTENSION pg_stat_statements;
  
  SELECT
      query,
      calls,
      total_time,
      mean_time,
      rows,
      100.0 * shared_blks_hit / (shared_blks_hit + shared_blks_read) AS hit_percent
  FROM
      pg_stat_statements
  ORDER BY
      total_time DESC
  LIMIT 10;
          

• pg_top / top / htop: ตรวจสอบการใช้งาน CPU, RAM, และ Disk I/O ในระดับ OS ครับ
• Prometheus + Grafana: สำหรับการ Monitoring แบบกราฟิกที่ละเอียดและสามารถเก็บข้อมูลย้อนหลังได้ครับ
• pg_buffercache: (ต้องติดตั้ง extension) ช่วยให้เห็นว่าข้อมูลใดอยู่ใน Shared Buffers และมีการใช้งานอย่างไรครับ
• pg_stat_user_tables / pg_stat_all_tables: ดูสถิติการใช้งานตาราง เช่น จำนวนการสแกน, จำนวน Insert/Update/Delete, และสถานะ Autovacuum ครับ

การวัด Baseline Performance

ก่อนที่เราจะเริ่มปรับแต่งใดๆ สิ่งสำคัญคือการวัดประสิทธิภาพปัจจุบันของระบบ หรือที่เรียกว่า “Baseline” ครับ การมี Baseline จะช่วยให้เราเปรียบเทียบผลลัพธ์หลังการปรับแต่งได้ และรู้ว่าการเปลี่ยนแปลงของเราส่งผลดีหรือผลเสียอย่างไรครับ

• บันทึก Metrics สำคัญๆ เช่น Average Query Response Time, Transactions Per Second (TPS), CPU Utilization, Memory Usage, Disk I/O (reads/writes per second) ครับ
• ใช้เครื่องมือ Load Testing เช่น pgbench หรือเครื่องมือเฉพาะทางสำหรับแอปพลิเคชันของคุณ เพื่อจำลองโหลดการทำงานจริงครับ

การระบุปัญหาคอขวด (Bottlenecks)

เมื่อเรามีเครื่องมือ Monitoring และ Baseline แล้ว ขั้นตอนต่อไปคือการระบุว่าปัญหาคอขวดอยู่ที่ส่วนใดของระบบครับ

• CPU Bound: Query ที่ซับซ้อน, การคำนวณจำนวนมาก, การ Join หลายตาราง, Index ที่ไม่มีประสิทธิภาพ
• Memory Bound: work_mem ต่ำเกินไปทำให้ต้องเขียนข้อมูลลงดิสก์ชั่วคราว, shared_buffers เล็กเกินไป, แอปพลิเคชันที่ใช้ RAM เยอะ
• I/O Bound: Query ที่ต้องอ่านข้อมูลจากดิสก์จำนวนมาก, Index ที่ขาดหายไป, Autovacuum ที่ทำงานหนัก, WAL ที่เขียนลงดิสก์บ่อยเกินไป
• Lock Contention: Transactions ที่รอนานเนื่องจากมีการ Lock ข้อมูลที่ใช้ร่วมกัน
• Network Bound: กรณีที่ฐานข้อมูลและแอปพลิเคชันอยู่คนละเครื่องและมีการส่งข้อมูลผ่านเครือข่ายจำนวนมาก

การระบุปัญหาที่ถูกต้องคือกุญแจสำคัญในการเลือกวิธีการปรับแต่งที่เหมาะสมครับ

Core Configuration Parameters: หัวใจของการปรับแต่ง

ไฟล์ postgresql.conf คือศูนย์รวมการตั้งค่าทั้งหมดของ PostgreSQL ครับ การปรับค่าพารามิเตอร์เหล่านี้อย่างถูกต้องสามารถส่งผลต่อประสิทธิภาพอย่างมหาศาลครับ

หมายเหตุ: ค่าที่แนะนำด้านล่างเป็นเพียงจุดเริ่มต้น การปรับค่าจริงควรพิจารณาจากทรัพยากรของเซิร์ฟเวอร์และลักษณะการใช้งานเป็นหลักครับ

shared_buffers

เป็นพารามิเตอร์ที่สำคัญที่สุดตัวหนึ่งครับ กำหนดขนาดของหน่วยความจำที่ PostgreSQL ใช้สำหรับแคชข้อมูลที่อ่านจากดิสก์

• ขนาดที่เหมาะสม: โดยทั่วไปแล้ว 25% ของ RAM ทั้งหมดของเซิร์ฟเวอร์เป็นค่าเริ่มต้นที่ดีครับ สำหรับเซิร์ฟเวอร์ที่มี RAM 64GB อาจตั้งค่าเป็น 16GB ครับ
• ข้อควรระวัง: การตั้งค่าสูงเกินไปอาจทำให้ระบบปฏิบัติการไม่มี RAM เพียงพอสำหรับส่วนอื่นๆ หรือทำให้เกิดการ Paging/Swapping ซึ่งจะทำให้ประสิทธิภาพแย่ลงกว่าเดิมครับ

# ใน postgresql.conf
shared_buffers = 16GB  # ตัวอย่างสำหรับเซิร์ฟเวอร์ 64GB RAM

work_mem

เป็นหน่วยความจำที่ใช้สำหรับ Sorting (เช่น ORDER BY, GROUP BY) และ Hashing (เช่น Hash Join) ครับ ซึ่งจะถูกจัดสรรให้แต่ละ Query แยกกัน

• ขนาดที่เหมาะสม: หากพบว่า Query มีการใช้ External Sort (เขียนลงดิสก์ชั่วคราว) บ่อยๆ (ดูได้จาก EXPLAIN ANALYZE) ควรเพิ่มค่านี้ครับ ค่าเริ่มต้นมักจะน้อยเกินไป (เช่น 4MB) อาจลองเพิ่มเป็น 16MB, 32MB, หรือ 64MB ครับ แต่ระวังว่าหากมี Connection ที่รัน Query ที่ต้อง Sort พร้อมกันหลายๆ Query อาจทำให้ใช้ RAM สูงมากจนหมดได้ครับ

# ใน postgresql.conf
work_mem = 32MB # ตัวอย่าง

maintenance_work_mem

หน่วยความจำที่ใช้สำหรับงานบำรุงรักษา เช่น VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY ครับ

• ขนาดที่เหมาะสม: สามารถตั้งค่าให้สูงกว่า work_mem ได้อย่างปลอดภัย เนื่องจากงานเหล่านี้ไม่ได้รันพร้อมกันบ่อยนักครับ การเพิ่มค่านี้จะช่วยให้งานบำรุงรักษาเหล่านี้ทำงานได้เร็วขึ้นอย่างมาก โดยเฉพาะการสร้าง Index ครับ อาจตั้งค่าเป็น 256MB ถึง 2GB ขึ้นอยู่กับ RAM ทั้งหมดครับ

# ใน postgresql.conf
maintenance_work_mem = 512MB # ตัวอย่าง

wal_buffers

หน่วยความจำสำหรับบัฟเฟอร์ WAL ก่อนที่จะเขียนลงดิสก์ครับ

• ขนาดที่เหมาะสม: โดยทั่วไปแล้ว 16MB เป็นค่าที่ดีสำหรับระบบที่มีการเขียนข้อมูลจำนวนมากครับ ไม่จำเป็นต้องตั้งค่าสูงมากเท่า shared_buffers ครับ

# ใน postgresql.conf
wal_buffers = 16MB # ตัวอย่าง

effective_cache_size

พารามิเตอร์นี้ไม่ได้จัดสรรหน่วยความจำจริง แต่เป็นค่าประมาณที่ Query Planner ใช้ในการคำนวณว่าข้อมูลส่วนใหญ่จะอยู่ใน OS Cache หรือไม่ เพื่อช่วยในการตัดสินใจเลือกแผนการทำงานที่ดีที่สุด

• ขนาดที่เหมาะสม: ควรตั้งค่าให้เป็น RAM ที่ว่างอยู่ทั้งหมดของระบบ หักลบด้วย shared_buffers และ RAM ที่แอปพลิเคชันอื่นๆ ใช้ไปครับ โดยทั่วไปแล้วอาจตั้งค่าเป็น 50-75% ของ RAM ทั้งหมดครับ

# ใน postgresql.conf
effective_cache_size = 48GB # ตัวอย่างสำหรับเซิร์ฟเวอร์ 64GB RAM (64GB - 16GB shared_buffers)

max_connections

จำนวนการเชื่อมต่อสูงสุดที่อนุญาตให้เข้ามายังฐานข้อมูลพร้อมกัน

• ขนาดที่เหมาะสม: ขึ้นอยู่กับจำนวน Connection ที่แอปพลิเคชันของคุณต้องการครับ การตั้งค่าสูงเกินไปโดยไม่จำเป็นจะสิ้นเปลือง RAM (แต่ละ Connection ใช้ RAM จำนวนหนึ่ง) และอาจนำไปสู่ปัญหา Lock Contention ได้ง่ายขึ้นครับ การใช้ Connection Pooler สามารถช่วยลดจำนวน Connection ที่เปิดค้างไว้กับฐานข้อมูลได้ครับ

# ใน postgresql.conf
max_connections = 100 # ตัวอย่าง

fsync และ synchronous_commit

เป็นพารามิเตอร์ที่เกี่ยวข้องกับความคงทนของข้อมูล (durability) และประสิทธิภาพการเขียน

• fsync = on: แนะนำให้เปิดใช้งานเสมอเพื่อความปลอดภัยของข้อมูล (data integrity) ครับ การปิด fsync อาจทำให้ข้อมูลเสียหายได้หากเกิดไฟดับหรือ Crash ครับ
• synchronous_commit = on: (Default) หมายความว่า Transaction จะไม่ถูกรายงานว่าสำเร็จจนกว่า WAL record จะถูกเขียนลงดิสก์อย่างถาวร หากประสิทธิภาพการเขียนเป็นปัญหาสำคัญและยอมรับความเสี่ยงที่จะสูญเสียข้อมูลเล็กน้อยในกรณีที่ Crash ได้ (เช่น ข้อมูลที่สามารถสร้างขึ้นใหม่ได้) สามารถตั้งค่าเป็น off หรือ local ได้ครับ แต่ต้องระมัดระวังเป็นอย่างสูงครับ

# ใน postgresql.conf
fsync = on
synchronous_commit = on # หรือ off/local หากยอมรับความเสี่ยงได้

Cost Parameters: random_page_cost, seq_page_cost และอื่นๆ

พารามิเตอร์เหล่านี้เป็นตัวเลขที่ Query Planner ใช้ในการประเมินค่าใช้จ่าย (cost) ของการอ่านข้อมูลแบบต่างๆ ครับ การปรับค่าเหล่านี้จะส่งผลต่อการตัดสินใจของ Planner ว่าจะใช้ Index หรือทำ Sequential Scan ดี

• random_page_cost: ค่าใช้จ่ายในการอ่านหน้าข้อมูลแบบสุ่ม (เช่น การใช้ Index) Default คือ 4.0
• seq_page_cost: ค่าใช้จ่ายในการอ่านหน้าข้อมูลแบบต่อเนื่อง (Sequential Scan) Default คือ 1.0
• การปรับแต่ง: หากใช้ SSD ควรลดค่า random_page_cost ลงให้ใกล้เคียงกับ seq_page_cost (เช่น random_page_cost = 1.1 หรือ 2.0) เพราะ SSD มีความเร็วในการอ่านแบบสุ่มสูงกว่า HDD มากครับ

# ใน postgresql.conf
random_page_cost = 1.1 # สำหรับ SSD
seq_page_cost = 1.0
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
cpu_operator_cost = 0.0025

Autovacuum-related Parameters

พารามิเตอร์เหล่านี้ควบคุมการทำงานของ Autovacuum ครับ

• autovacuum = on: ควรเปิดใช้งานเสมอครับ
• autovacuum_max_workers: จำนวน Worker สูงสุดที่ Autovacuum สามารถรันพร้อมกันได้ครับ (Default 3)
• autovacuum_vacuum_scale_factor, autovacuum_vacuum_threshold: กำหนดว่าจะเริ่ม Vacuum เมื่อมี Dead Tuples ถึงเกณฑ์เท่าไหร่ครับ
• autovacuum_analyze_scale_factor, autovacuum_analyze_threshold: กำหนดว่าจะเริ่ม Analyze เมื่อมีการเปลี่ยนแปลงข้อมูลถึงเกณฑ์เท่าไหร่ครับ
• autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit: ควบคุมความเร็วในการ Vacuum เพื่อไม่ให้กระทบต่อการทำงานปกติของฐานข้อมูลมากเกินไปครับ

เราจะเจาะลึกเรื่อง Autovacuum อีกครั้งในหัวข้อถัดไปครับ แต่สำหรับตอนนี้ การเปิดใช้งานและปรับค่าเริ่มต้นให้เหมาะสมก็เป็นสิ่งสำคัญครับ

# ใน postgresql.conf
autovacuum = on
autovacuum_max_workers = 5 # เพิ่มจำนวน worker สำหรับระบบที่มีกิจกรรมสูง
autovacuum_vacuum_cost_delay = 10ms # ลด delay เพื่อให้ vacuum ทำงานเร็วขึ้น
# autovacuum_vacuum_scale_factor และ threshold สามารถปรับละเอียดได้ในระดับตาราง

Indexing Strategies: การสร้าง Index อย่างชาญฉลาด

Index เป็นเครื่องมือสำคัญในการปรับปรุงประสิทธิภาพของ Query ที่ต้องค้นหาข้อมูลจำนวนมาก แต่การสร้าง Index มากเกินไปหรือสร้าง Index ที่ไม่เหมาะสมก็อาจทำให้ประสิทธิภาพแย่ลงได้เช่นกันครับ เพราะทุกครั้งที่มีการ Insert, Update, Delete ข้อมูล Index ก็ต้องได้รับการอัปเดตด้วย ซึ่งจะเพิ่มภาระ I/O และขนาดของฐานข้อมูลครับ

ประเภทของ Index และการเลือกใช้งาน

PostgreSQL มี Index หลายประเภท แต่ละประเภทเหมาะกับการใช้งานที่แตกต่างกันครับ

เมื่อไหร่ควรสร้าง Index และเมื่อไหร่ไม่ควร

• ควรสร้าง Index เมื่อ:
  • คอลัมน์นั้นถูกใช้บ่อยใน WHERE clause (โดยเฉพาะ =, <, >)
  • คอลัมน์นั้นถูกใช้ใน ORDER BY หรือ GROUP BY
  • คอลัมน์นั้นเป็นส่วนหนึ่งของ JOIN condition
  • คอลัมน์นั้นมี Cardinality สูง (ค่าไม่ซ้ำกันจำนวนมาก)
  • Primary Keys และ Foreign Keys ควรมี Index เสมอ
• ไม่ควรสร้าง Index เมื่อ:
  • ตารางมีขนาดเล็กมาก (PostgreSQL สามารถทำ Sequential Scan ได้เร็วกว่าการใช้ Index)
  • คอลัมน์นั้นมี Cardinality ต่ำมาก (เช่น คอลัมน์เพศ ‘ชาย’/’หญิง’) – Index อาจไม่มีประโยชน์
  • ตารางมีการ Insert/Update/Delete บ่อยมาก และ Query ที่ต้องอ่านข้อมูลไม่ได้เป็นปัญหาประสิทธิภาพ
  • Index ที่ไม่ได้ถูกใช้งานเลย (ตรวจสอบได้จาก pg_stat_user_indexes)

Partial Indexes และ Expression Indexes

• Partial Index: Index เฉพาะส่วนหนึ่งของตาราง เช่น CREATE INDEX ON orders (order_date) WHERE status = 'completed'; ช่วยลดขนาดของ Index และเพิ่มประสิทธิภาพในการค้นหาสำหรับกรณีเฉพาะครับ
• Expression Index: Index ผลลัพธ์จากการใช้ Function หรือ Expression เช่น CREATE INDEX ON users (lower(email)); เพื่อให้ Query ที่ใช้ lower(email) สามารถใช้ Index ได้ครับ

-- Partial Index
CREATE INDEX idx_orders_completed_date ON orders (order_date) WHERE status = 'completed';

-- Expression Index
CREATE INDEX idx_users_email_lower ON users (lower(email));

REINDEX vs CREATE INDEX CONCURRENTLY

• REINDEX: สร้าง Index ใหม่ทั้งหมด ซึ่งจะล็อคตาราง (exclusive lock) ทำให้ไม่สามารถเขียนข้อมูลลงตารางได้ในขณะที่ Index กำลังถูกสร้าง เหมาะสำหรับช่วง Downtime หรือตารางขนาดเล็กครับ
• CREATE INDEX CONCURRENTLY: สร้าง Index โดยไม่ล็อคตาราง (shared lock) ทำให้สามารถอ่านและเขียนข้อมูลได้ตามปกติ แต่จะใช้เวลานานกว่าและใช้ทรัพยากรมากกว่า และหากเกิดข้อผิดพลาดระหว่างสร้าง Index จะต้องลบ Index ที่สร้างไม่เสร็จทิ้งไปเองครับ เป็นวิธีที่แนะนำสำหรับการสร้าง Index บน Production Database ครับ

-- สร้าง Index แบบปกติ (ล็อคตาราง)
CREATE INDEX idx_products_name ON products (name);

-- สร้าง Index แบบไม่ล็อคตาราง (แนะนำสำหรับ Production)
CREATE INDEX CONCURRENTLY idx_products_description ON products (description);

จำไว้ว่า การสร้าง Index ที่ดีคือการสร้าง Index ที่ถูกใช้ และสร้างเฉพาะที่จำเป็นเท่านั้นครับ

Query Optimization: ปรับแต่ง SQL Query ให้เร็วสุดขีด

บ่อยครั้งที่ปัญหาประสิทธิภาพไม่ได้อยู่ที่การตั้งค่าเซิร์ฟเวอร์ แต่อยู่ที่การเขียน Query ที่ไม่มีประสิทธิภาพครับ การปรับแต่ง Query สามารถให้ผลลัพธ์ที่น่าทึ่งได้ครับ

ทำความเข้าใจ EXPLAIN และ EXPLAIN ANALYZE

นี่คือเครื่องมือที่สำคัญที่สุดในการวิเคราะห์ Query Performance ครับ

• EXPLAIN: แสดงแผนการทำงานที่ Query Planner เลือก (Execution Plan) โดยไม่ได้รัน Query จริงๆ เหมาะสำหรับดูว่า Index ถูกใช้หรือไม่, มีการทำ Sequential Scan ที่ไม่จำเป็นหรือไม่
• EXPLAIN ANALYZE: รัน Query จริงๆ และแสดง Execution Plan พร้อมกับสถิติเวลาที่ใช้ไปในแต่ละขั้นตอน, จำนวนแถวที่คืนค่า, และค่าใช้จ่ายอื่นๆ เป็นเครื่องมือที่ละเอียดกว่าและให้ข้อมูลเชิงลึกที่แม่นยำกว่าครับ

-- ดูแผนการทำงาน
EXPLAIN SELECT * FROM users WHERE email LIKE 'john%';

-- ดูแผนการทำงานพร้อมสถิติเวลาจริง
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT
    o.order_id,
    u.username,
    oi.product_name,
    oi.quantity
FROM
    orders o
JOIN
    users u ON o.user_id = u.user_id
JOIN
    order_items oi ON o.order_id = oi.order_id
WHERE
    o.order_date BETWEEN '2023-01-01' AND '2023-01-31'
    AND u.status = 'active'
ORDER BY
    o.order_date DESC
LIMIT 100;

เมื่อใช้ EXPLAIN ANALYZE ให้สังเกตค่า "actual time" สำหรับแต่ละ Node, "rows removed by filter", "rows removed by join filter", และ "Buffers" เพื่อดูว่าส่วนไหนของ Query ใช้เวลามากที่สุด หรือมีการอ่านข้อมูลจากดิสก์มากเกินไปครับ หากเห็น "Sort Method: external merge Disk" แสดงว่า work_mem อาจไม่เพียงพอครับ

หลีกเลี่ยง SELECT *

การเลือกทุกคอลัมน์โดยใช้ SELECT * มักจะไม่จำเป็นและทำให้ Query ดึงข้อมูลที่ไม่เกี่ยวข้องออกมาจำนวนมาก ทำให้สิ้นเปลือง I/O, หน่วยความจำ, และแบนด์วิดท์เครือข่าย ควรเลือกเฉพาะคอลัมน์ที่จำเป็นเท่านั้นครับ

-- ไม่แนะนำ
SELECT * FROM products;

-- แนะนำ
SELECT product_id, product_name, price FROM products;

การใช้ JOINs อย่างมีประสิทธิภาพ

• เลือกประเภท JOIN ที่เหมาะสม: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN มีความหมายและการใช้งานที่แตกต่างกัน เลือกให้ถูกตามความต้องการครับ
• Index บน Join Conditions: ตรวจสอบให้แน่ใจว่าคอลัมน์ที่ใช้ใน ON clause ของ JOIN มี Index ที่เหมาะสมครับ
• ลำดับของ JOIN: Query Planner จะพยายามหาลำดับการ Join ที่ดีที่สุด แต่บางครั้งการช่วย Planner โดยการจัดลำดับตารางเล็กเข้ากับตารางใหญ่ก่อน อาจช่วยได้ครับ

Subqueries vs JOINs

หลายครั้งที่ Subquery สามารถเขียนใหม่ในรูปของ JOIN ได้ ซึ่งมักจะมีประสิทธิภาพที่ดีกว่า โดยเฉพาะอย่างยิ่ง EXISTS หรือ IN Subquery ที่สามารถเขียนเป็น INNER JOIN หรือ LEFT JOIN กับ DISTINCT ได้ครับ

-- Subquery (อาจช้า)
SELECT * FROM users WHERE user_id IN (SELECT user_id FROM orders WHERE amount > 100);

-- JOIN (มักจะเร็วกว่า)
SELECT DISTINCT u.*
FROM users u
JOIN orders o ON u.user_id = o.user_id
WHERE o.amount > 100;

Common Table Expressions (CTEs)

CTEs (ใช้ WITH clause) ช่วยให้ Query อ่านง่ายขึ้นและสามารถนำผลลัพธ์ไปใช้ซ้ำได้ ซึ่งบางครั้งอาจช่วยให้ Planner ทำงานได้ดีขึ้น แต่ก็ไม่ได้ช่วยเรื่องประสิทธิภาพเสมอไป หากมี CTEs ที่ซับซ้อน ควรตรวจสอบ EXPLAIN ANALYZE อย่างละเอียดครับ

WITH RecentOrders AS (
    SELECT order_id, user_id, order_date, total_amount
    FROM orders
    WHERE order_date >= NOW() - INTERVAL '1 month'
)
SELECT u.username, ro.total_amount
FROM users u
JOIN RecentOrders ro ON u.user_id = ro.user_id
ORDER BY ro.total_amount DESC;

การปรับแต่ง WHERE clause

• ใช้ Index ที่ถูกต้อง: ตรวจสอบว่าเงื่อนไขใน WHERE clause สามารถใช้ Index ได้ (SARGable – Search Argumentable) เช่น column = 'value' หรือ column > 10 ครับ
• หลีกเลี่ยง Function บนคอลัมน์ Index: หากใช้ Function บนคอลัมน์ที่มี Index เช่น WHERE lower(column) = 'value' Index จะไม่ถูกใช้ (ยกเว้น Expression Index) ครับ
• ใช้ LIMIT: หากต้องการข้อมูลเพียงบางส่วน ให้ใช้ LIMIT เสมอเพื่อลดปริมาณข้อมูลที่ต้องประมวลผล

การใช้ Function และ Operator

บาง Function และ Operator อาจมีประสิทธิภาพมากกว่าแบบอื่น เช่น:

• ใช้ LIKE 'prefix%' แทน LIKE '%suffix' หรือ '%substring%' เพราะ LIKE 'prefix%' สามารถใช้ B-tree Index ได้ครับ
• พิจารณาใช้ ILIKE สำหรับการค้นหาแบบ Case-Insensitive แทน lower(column) = lower('value') หากไม่มี Expression Index บน lower(column)
• สำหรับ Full-Text Search ควรใช้ Full-Text Search features ของ PostgreSQL (tsvector, tsquery, GIN/GiST Index) แทน LIKE ครับ

การปรับแต่ง Query เป็นศิลปะที่ต้องใช้การฝึกฝนและการวิเคราะห์ EXPLAIN ANALYZE อย่างสม่ำเสมอครับ

Autovacuum Tuning: การจัดการ Dead Tuples อย่างมีประสิทธิภาพ

Autovacuum เป็นกระบวนการที่สำคัญอย่างยิ่งสำหรับ PostgreSQL เนื่องจากสถาปัตยกรรม MVCC ครับ หากไม่มี Autovacuum หรือ Autovacuum ทำงานได้ไม่ดี ฐานข้อมูลจะประสบปัญหา Dead Tuples สะสม, ขนาดตารางบวมขึ้น, Query ช้าลง, และที่เลวร้ายที่สุดคือ Transaction ID Wraparound ซึ่งทำให้ฐานข้อมูลไม่สามารถเขียนข้อมูลได้อีกต่อไปครับ

กลไกการทำงานของ Autovacuum

Autovacuum เป็น Daemon ที่รันอยู่เบื้องหลัง มันจะคอยตรวจสอบตารางต่างๆ ในฐานข้อมูล และเมื่อมีจำนวน Dead Tuples ถึงเกณฑ์ที่กำหนด (threshold + scale factor * table_rows) มันก็จะเรียก VACUUM เพื่อกวาดล้าง Dead Tuples และ ANALYZE เพื่ออัปเดตสถิติของตารางครับ

พารามิเตอร์สำคัญของ Autovacuum

พารามิเตอร์เหล่านี้สามารถตั้งค่าได้ทั้งใน postgresql.conf (สำหรับทั้งระบบ) หรือในระดับตารางด้วย ALTER TABLE ครับ

• autovacuum_vacuum_scale_factor (Default: 0.2): สัดส่วนของ Dead Tuples เทียบกับจำนวนแถวทั้งหมดของตาราง ที่จะกระตุ้นให้เกิด Vacuum
• autovacuum_vacuum_threshold (Default: 50): จำนวน Dead Tuples ขั้นต่ำที่จะกระตุ้นให้เกิด Vacuum
• autovacuum_analyze_scale_factor (Default: 0.1): สัดส่วนของการเปลี่ยนแปลงข้อมูล ที่จะกระตุ้นให้เกิด Analyze
• autovacuum_analyze_threshold (Default: 50): จำนวนการเปลี่ยนแปลงข้อมูลขั้นต่ำ ที่จะกระตุ้นให้เกิด Analyze
• autovacuum_vacuum_cost_delay (Default: 2ms): ระยะเวลาที่ Worker จะหยุดพักหลังจากประมวลผลข้อมูลไปถึง autovacuum_vacuum_cost_limit ช่วยควบคุมภาระ I/O
• autovacuum_vacuum_cost_limit (Default: 200): ปริมาณ “cost units” ที่ Autovacuum Worker สามารถใช้ได้ก่อนที่จะหยุดพัก

คำแนะนำในการปรับแต่ง:

• สำหรับตารางที่มีการ Insert/Update/Delete บ่อยมาก ควรลด scale_factor ลง (เช่น 0.05 หรือ 0.1) และอาจเพิ่ม threshold เล็กน้อย เพื่อให้ Autovacuum ทำงานบ่อยขึ้นครับ
• สำหรับตารางขนาดใหญ่มากที่มีการเปลี่ยนแปลงข้อมูลบ่อย การลด autovacuum_vacuum_cost_delay ลง (เช่น 10ms หรือ 5ms) อาจช่วยให้ Vacuum ทำงานได้เร็วขึ้น แต่ต้องระวังไม่ให้ไปรบกวนการทำงานปกติของฐานข้อมูลมากเกินไปครับ
• สามารถปรับค่าเหล่านี้ในระดับตารางได้ เช่น:

  
  ALTER TABLE large_transactions SET (
      autovacuum_vacuum_scale_factor = 0.01,
      autovacuum_vacuum_threshold = 1000,
      autovacuum_vacuum_cost_delay = 5
  );
          

การ Monitoring กิจกรรมของ Autovacuum

ใช้ pg_stat_user_tables หรือ pg_stat_all_tables เพื่อดูสถิติการ Vacuum และ Analyze:

SELECT
    relname,
    n_live_tuples,
    n_dead_tuples,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze,
    autovacuum_count,
    autoanalyze_count
FROM
    pg_stat_user_tables
ORDER BY
    n_dead_tuples DESC;

หากเห็น n_dead_tuples สูงขึ้นเรื่อยๆ หรือ last_autovacuum นานมาแล้ว แสดงว่า Autovacuum อาจทำงานไม่ทัน หรือตั้งค่าไม่เหมาะสมครับ

การเข้าใจและปรับแต่ง Autovacuum เป็นสิ่งสำคัญที่จะทำให้ PostgreSQL ของคุณทำงานได้อย่างมีประสิทธิภาพและเสถียรในระยะยาวครับ

Disk I/O Optimization: เพิ่มความเร็วในการอ่าน/เขียนข้อมูล

ประสิทธิภาพของ Disk I/O เป็นปัจจัยสำคัญที่ส่งผลต่อความเร็วของฐานข้อมูลอย่างมากครับ โดยเฉพาะเมื่อข้อมูลมีขนาดใหญ่และไม่สามารถเก็บไว้ใน RAM ได้ทั้งหมด

การเลือก Storage ที่เหมาะสม (SSD vs HDD)

• SSD (Solid State Drive): ให้ประสิทธิภาพ I/O ที่สูงกว่า HDD อย่างเห็นได้ชัด โดยเฉพาะการอ่าน/เขียนแบบสุ่ม (random I/O) ซึ่งเป็นลักษณะการทำงานปกติของฐานข้อมูลครับ แนะนำให้ใช้ SSD สำหรับ Production Database เสมอครับ
• HDD (Hard Disk Drive): ราคาถูกกว่า มีความจุสูงกว่า แต่ประสิทธิภาพ I/O ต่ำกว่ามาก โดยเฉพาะ Random I/O เหมาะสำหรับเก็บข้อมูลสำรอง (backup) หรือ Archive ที่ไม่ต้องการประสิทธิภาพสูงครับ

RAID Configurations

การใช้ RAID (Redundant Array of Independent Disks) ช่วยเพิ่มทั้งประสิทธิภาพและความทนทานของข้อมูล

• RAID 1 (Mirroring): เพิ่มความทนทาน, ประสิทธิภาพการอ่านดีขึ้น แต่ประสิทธิภาพการเขียนเท่าเดิม
• RAID 10 (Stripe of Mirrors): เป็นการรวมกันของ RAID 0 และ RAID 1 ให้ทั้งประสิทธิภาพที่สูง (ทั้งอ่านและเขียน) และความทนทานของข้อมูล เป็นตัวเลือกที่ดีที่สุดสำหรับฐานข้อมูลครับ
• RAID 5 / RAID 6: ประหยัดพื้นที่ได้ดี แต่ประสิทธิภาพการเขียนมักจะต่ำกว่า RAID 10 และมี Overhead ในการคำนวณ Parity ครับ

การแยก Data Directories

การแยกไฟล์ประเภทต่างๆ ไปยังดิสก์หรือ Volume ที่แตกต่างกันสามารถช่วยลด Contention ของ I/O ได้ครับ

• Data Files: เก็บไฟล์ข้อมูลหลักของฐานข้อมูล
• WAL Files: ควรแยก WAL ไปยังดิสก์ที่มีประสิทธิภาพ I/O สูงและมีความทนทาน (เช่น NVMe SSD) เนื่องจาก WAL มีการเขียนแบบต่อเนื่องบ่อยครั้งครับ
• Temporary Files: ไฟล์ชั่วคราวที่เกิดจากการ Sorting หรือ Hashing ที่เกิน work_mem อาจแยกไปไว้ในดิสก์ที่เร็ว
• TableSpaces: ใช้ CREATE TABLESPACE เพื่อแยกตารางหรือ Index ไปยังดิสก์ที่แตกต่างกันตามความเหมาะสมครับ

Filesystem Tuning

• Mount Options:
  • noatime: ปิดการอัปเดตเวลาเข้าถึงไฟล์ (access time) ซึ่งช่วยลด I/O ได้
  • data=ordered (สำหรับ ext3/ext4): เป็น Default อยู่แล้ว
  • commit=N: สำหรับ ext3/ext4 กำหนดเวลาในการเขียนข้อมูลจาก Journal ลงดิสก์ (N วินาที) ค่าเริ่มต้นคือ 5 วินาที การเพิ่มค่านี้อาจช่วยลด I/O แต่เพิ่มความเสี่ยงในการสูญเสียข้อมูลเล็กน้อยหากเกิด Crash ครับ
• Over-provisioning SSD: การจัดสรรพื้นที่ SSD ไว้ส่วนหนึ่ง (เช่น 10-20%) สำหรับการใช้งานภายในของ SSD (เช่น Wear Leveling, Garbage Collection) ช่วยรักษาประสิทธิภาพในระยะยาวครับ

การลงทุนใน Storage ที่ดีและการปรับแต่ง Disk I/O อย่างเหมาะสม จะเป็นรากฐานสำคัญของฐานข้อมูลที่มีประสิทธิภาพสูงครับ

Connection Pooling: จัดการการเชื่อมต่อให้เกิดประโยชน์สูงสุด

การสร้างและทำลาย Connection ไปยังฐานข้อมูลเป็นกระบวนการที่มีค่าใช้จ่ายสูงครับ โดยเฉพาะเมื่อแอปพลิเคชันมีการเชื่อมต่อและตัดการเชื่อมต่อบ่อยครั้ง หรือมีจำนวน Connection สูง การใช้ Connection Pooler จะช่วยจัดการปัญหานี้ได้ครับ

ทำไมต้องใช้ Connection Pooler?

• ลด Overhead การสร้าง Connection: Connection Pooler จะสร้าง Pool ของ Connection ที่เปิดค้างไว้กับฐานข้อมูล และนำ Connection เหล่านั้นมาใช้ซ้ำเมื่อแอปพลิเคชันต้องการ
• จำกัดจำนวน Connection: ช่วยจำกัดจำนวน Connection ที่เปิดไปยังฐานข้อมูลจริง ทำให้ max_connections ของ PostgreSQL ไม่ต้องตั้งค่าสูงเกินไป
• เพิ่ม Throughput: โดยการลดเวลาในการสร้าง Connection และลดภาระของฐานข้อมูล

ตัวอย่าง Connection Pooler ยอดนิยม:

• pgBouncer: น้ำหนักเบา, ประสิทธิภาพสูง, เหมาะสำหรับ Connection Pooling เพียงอย่างเดียว
• Pgpool-II: มีฟีเจอร์มากกว่า pgBouncer เช่น Load Balancing, Replication, Connection Pooling

ข้อดีและข้อเสียของการใช้ Connection Pooler

• ข้อดี:
  • ลด Latency ในการเชื่อมต่อ
  • ลดภาระของฐานข้อมูล
  • ควบคุมจำนวน Connection ได้ดีขึ้น
  • เพิ่มความเสถียรของระบบ
• ข้อเสีย:
  • เพิ่ม Complexity ให้กับสถาปัตยกรรม
  • ต้องมีการตั้งค่าและดูแลรักษา Pooler
  • อาจมีปัญหาเรื่อง Transaction State หรือ Session State หากตั้งค่าไม่ถูกต้อง

สำหรับแอปพลิเคชันที่มี Load สูง Connection Pooler ถือเป็นสิ่งจำเป็นอย่างยิ่งครับ

Partitioning: การแบ่งข้อมูลขนาดใหญ่เพื่อประสิทธิภาพ

Partitioning คือการแบ่งตารางขนาดใหญ่ออกเป็นตารางย่อยๆ (partitions) ที่มีขนาดเล็กลง แต่ยังคงทำงานเหมือนเป็นตารางเดียวเมื่อ Query ครับ การทำ Partitioning มีประโยชน์อย่างมากสำหรับตารางที่มีข้อมูลจำนวนมหาศาลครับ

Declarative Partitioning

PostgreSQL เวอร์ชัน 10 ขึ้นไปรองรับ Declarative Partitioning ซึ่งทำให้การจัดการ Partition ทำได้ง่ายขึ้นมากครับ

-- สร้างตารางหลัก (Parent Table)
CREATE TABLE sensor_data (
    log_id BIGSERIAL,
    device_id INT NOT NULL,
    log_time TIMESTAMP NOT NULL,
    temperature NUMERIC,
    humidity NUMERIC
) PARTITION BY RANGE (log_time); -- แบ่งตามช่วงเวลา

-- สร้าง Partition ย่อย (Child Tables)
CREATE TABLE sensor_data_2023_q1 PARTITION OF sensor_data
FOR VALUES FROM ('2023-01-01') TO ('2023-04-01');

CREATE TABLE sensor_data_2023_q2 PARTITION OF sensor_data
FOR VALUES FROM ('2023-04-01') TO ('2023-07-01');

-- เพิ่ม Partition ใหม่สำหรับข้อมูลที่จะเข้ามาในอนาคต
CREATE TABLE sensor_data_default PARTITION OF sensor_data DEFAULT;

ประโยชน์ของการ Partitioning

• ปรับปรุง Query Performance: เมื่อ Query มีเงื่อนไขใน WHERE clause ที่ตรงกับ Key ของ Partitioning (เช่น WHERE log_time BETWEEN ...) Query Planner สามารถทำ Partition Pruning ได้ คือจะสแกนเฉพาะ Partition ที่เกี่ยวข้องเท่านั้น ทำให้ลดปริมาณข้อมูลที่ต้องประมวลผลลงอย่างมากครับ
• ปรับปรุง Maintenance:
  • การ Vacuum หรือ Analyze ทำได้เร็วขึ้น เพราะทำกับ Partition ย่อย
  • การลบข้อมูลเก่าทำได้ง่ายและรวดเร็ว โดยการ Dropping Partition ทั้ง Partition แทนการ Delete แถวจำนวนมาก
  • การสร้าง Index ทำได้เร็วขึ้นบน Partition ย่อย
• ลดขนาด Index: Index บน Partition ย่อยจะมีขนาดเล็กกว่า Index บนตารางหลักทั้งหมด

ข้อควรพิจารณา

• การเลือก Partition Key: ควรเลือก Key ที่มีการกระจายตัวของข้อมูลดี และมักถูกใช้ใน WHERE clause เช่น log_time, customer_id
• จำนวน Partition: ไม่ควรมี Partition มากเกินไป เพราะจะเพิ่ม Overhead ในการจัดการ
• Query ที่ไม่ใช้ Partition Key: Query ที่ไม่ได้ใช้ Partition Key ใน WHERE clause อาจต้องสแกนทุก Partition ซึ่งจะช้ากว่าปกติครับ

Partitioning เป็นเทคนิคที่มีประสิทธิภาพสูงสำหรับตารางขนาดใหญ่ แต่ต้องมีการวางแผนที่ดีครับ

Advanced Tuning Techniques: เทคนิคขั้นสูง

เมื่อคุณปรับแต่งพื้นฐานและ Query ได้ดีแล้ว ยังมีเทคนิคขั้นสูงบางอย่างที่สามารถช่วยเพิ่มประสิทธิภาพได้อีกครับ

JIT Compilation (PostgreSQL 11+)

PostgreSQL 11 ได้นำเสนอ JIT (Just-In-Time) Compilation ที่ใช้ LLVM เพื่อคอมไพล์ส่วนหนึ่งของ Execution Plan ให้เป็น Machine Code ซึ่งสามารถรันได้เร็วกว่า โดยเฉพาะสำหรับ Query ที่ซับซ้อนและมีการประมวลผลจำนวนมากครับ

# ใน postgresql.conf
jit = on
# jit_provider = 'llvm' (Default)
# jit_optimize_debug = off
# jit_above_cost = 100000 (ค่าใช้จ่ายของ Query ที่จะเริ่มใช้ JIT)
# jit_inline_above_cost = 500000
# jit_analyze_qual_tool_cost = 10000

Parallel Query (PostgreSQL 9.6+)

PostgreSQL สามารถใช้หลาย CPU Cores เพื่อรัน Query บางประเภทพร้อมกัน (Parallel Execution) ช่วยลดเวลาในการประมวลผลสำหรับ Query ที่ต้องสแกนข้อมูลจำนวนมากหรือทำ Aggregation ครับ

• max_parallel_workers_per_gather: จำนวน Worker สูงสุดที่แต่ละ Query สามารถใช้ได้ (Default 2)
• max_parallel_workers: จำนวน Worker สูงสุดที่สามารถรันพร้อมกันได้ทั่วทั้งระบบ
• max_worker_processes: จำนวน Process Worker ทั้งหมด (รวม Autovacuum, Logical Replication)
• min_parallel_table_scan_size: ขนาดตารางขั้นต่ำที่จะเริ่มพิจารณาทำ Parallel Scan

Query Planner จะตัดสินใจเองว่าจะใช้ Parallel Execution หรือไม่ หากเห็น Gather Node ใน EXPLAIN ANALYZE นั่นหมายความว่ามีการใช้ Parallel Query ครับ

# ใน postgresql.conf
max_worker_processes = 8 # ตัวอย่างสำหรับ 8 Cores CPU
max_parallel_workers = 8
max_parallel_workers_per_gather = 4

Custom Cost Factors

นอกจากการปรับ random_page_cost และ seq_page_cost แล้ว ยังมีพารามิเตอร์อื่นๆ ที่เกี่ยวข้องกับ Cost Model ที่สามารถปรับได้ เช่น cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost หากคุณมีความเข้าใจเชิงลึกเกี่ยวกับ Workload ของคุณ อาจปรับค่าเหล่านี้เพื่อ “ชี้นำ” Query Planner ให้เลือกแผนการทำงานที่เหมาะสมกับฮาร์ดแวร์ของคุณมากขึ้นครับ

Caching ที่ Application Layer

บางครั้งปัญหาประสิทธิภาพไม่ได้อยู่ที่ฐานข้อมูลโดยตรง แต่อยู่ที่การเรียกข้อมูลซ้ำๆ บ่อยครั้งจากแอปพลิเคชัน การใช้ Cache Mechanism ที่ Application Layer (เช่น Redis, Memcached) สำหรับข้อมูลที่ไม่เปลี่ยนแปลงบ่อย หรือข้อมูลที่ใช้ซ้ำๆ สามารถลดภาระของฐานข้อมูลได้อย่างมาก และเพิ่ม Response Time ของแอปพลิเคชันได้เป็นอย่างดีครับ

Monitoring และ Maintenance: การเฝ้าระวังและการบำรุงรักษา

การปรับแต่งไม่ใช่การทำครั้งเดียวจบ แต่เป็นการดำเนินการอย่างต่อเนื่อง การ Monitoring และ Maintenance อย่างสม่ำเสมอเป็นสิ่งสำคัญเพื่อให้ฐานข้อมูลของคุณทำงานได้อย่างมีประสิทธิภาพในระยะยาวครับ

Metrics ที่จำเป็นสำหรับการ Monitoring

• Query Performance: Average Query Time, Slow Query Count, TPS (Transactions Per Second)
• Resource Usage: CPU Utilization, Memory Usage, Disk I/O (Read/Write Latency, Throughput), Network I/O
• Database Specific Metrics:
  • Active Connections, Idle In Transaction Connections
  • Cache Hit Ratio (จาก pg_stat_database)
  • Dead Tuples (จาก pg_stat_user_tables)
  • Autovacuum Activity
  • Replication Lag (หากมีการทำ Replication)

เครื่องมือเช่น Prometheus + Grafana, Datadog, New Relic สามารถช่วยในการเก็บและแสดงผล Metrics เหล่านี้ได้อย่างมีประสิทธิภาพครับ

Regular Maintenance Tasks

• VACUUM FULL: (ระวัง! ล็อคตาราง) ใช้เพื่อเรียกคืนพื้นที่ดิสก์ที่ถูกใช้ไปโดย Dead Tuples อย่างถาวร ควรทำเมื่อจำเป็นจริงๆ และในช่วง Downtime เนื่องจากจะล็อคตารางและเขียนตารางใหม่ทั้งหมดครับ
• REINDEX DATABASE / REINDEX TABLE: (ระวัง! ล็อคตาราง) ใช้เพื่อสร้าง Index ใหม่ทั้งหมด ช่วยจัดระเบียบ Index ที่อาจ Fragmented ไปตามกาลเวลา ควรทำในช่วง Downtime หรือใช้ CREATE INDEX CONCURRENTLY แล้วลบ Index เก่าทิ้งแทนครับ
• ANALYZE: อัปเดตสถิติของตาราง ซึ่งสำคัญมากสำหรับ Query Planner เพื่อเลือกแผนการทำงานที่ดีที่สุด Autovacuum จะทำ Analyze ให้อยู่แล้ว แต่บางครั้งอาจต้องรันด้วยตนเองหากมีการเปลี่ยนแปลงข้อมูลจำนวนมากอย่างรวดเร็วครับ
• Backup and Restore Tests: การสำรองข้อมูลเป็นสิ่งสำคัญ แต่การทดสอบ Restore ก็สำคัญไม่แพ้กัน เพื่อให้แน่ใจว่าข้อมูลสามารถกู้คืนได้จริงเมื่อเกิดเหตุการณ์ไม่คาดฝัน

-- รัน VACUUM FULL (ล็อคตาราง)
VACUUM FULL VERBOSE table_name;

-- รัน REINDEX (ล็อคตาราง)
REINDEX TABLE table_name;

-- รัน ANALYZE
ANALYZE table_name;

Logging ที่มีประโยชน์

การตั้งค่า Logging ให้ดีจะช่วยในการวิเคราะห์ปัญหาประสิทธิภาพได้

• log_min_duration_statement = 100ms: บันทึก Query ทุกตัวที่ใช้เวลานานกว่า 100 มิลลิวินาที ช่วยให้คุณระบุ Slow Query ได้อย่างรวดเร็ว
• log_statement = 'ddl': บันทึกคำสั่ง DDL (เช่น CREATE TABLE, ALTER TABLE)
• log_connections = on, log_disconnections = on: บันทึกการเชื่อมต่อและตัดการเชื่อมต่อ
• log_autovacuum_min_duration = 0: บันทึกทุกกิจกรรมของ Autovacuum เพื่อดูว่ามันทำงานอย่างไรและบ่อยแค่ไหน

การมีข้อมูลเหล่านี้ใน Log จะเป็นประโยชน์อย่างมากในการ Debug และปรับแต่งระบบครับ

FAQ: คำถามที่พบบ่อยเกี่ยวกับการปรับแต่ง PostgreSQL

เพื่อให้การปรับแต่ง PostgreSQL ของคุณเป็นไปอย่างราบรื่นและมีประสิทธิภาพสูงสุด เราได้รวบรวมคำถามที่พบบ่อยพร้อมคำตอบมาให้ทุกท่านได้ศึกษาเพิ่มเติมครับ

1. ควรเริ่มปรับแต่งจากจุดไหนเป็นอันดับแรก?

คำตอบ: อันดับแรกและสำคัญที่สุดคือการ Monitoring ครับ คุณต้องรู้ก่อนว่าปัญหาคอขวดอยู่ที่ไหน (CPU, RAM, Disk I/O, หรือ Query) จากนั้นจึงค่อยเริ่มปรับแต่งตามลำดับดังนี้