ความสามารถใหม่ของตัววางแผนคิวรีใน Postgres 16

 (citusdata.com)
1 คะแนน โดย GN⁺ 2024-02-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ความสามารถใหม่ของตัววางแผนคิวรีใน PostgreSQL 16

  • PostgreSQL 16 ได้นำการปรับปรุงจำนวนมากเข้าสู่ตัววางแผนคิวรี ทำให้คิวรี SQL จำนวนมากทำงานได้เร็วกว่าเวอร์ชันก่อนหน้า
  • แม้จะสามารถดูการปรับปรุงของตัววางแผนเหล่านี้ได้ในบันทึกประจำรุ่นของ PG16 แต่ในแต่ละรีลีสของ PostgreSQL มีการเปลี่ยนแปลงมากมาย จึงยากที่จะอธิบายรายละเอียดของแต่ละการเปลี่ยนแปลงได้ครบถ้วน
  • โพสต์บล็อกนี้นำเสนอการวิเคราะห์เชิงลึกของการปรับปรุง 10 ประการในตัววางแผนคิวรีของ PostgreSQL 16 พร้อมเปรียบเทียบผลลัพธ์ของตัววางแผนระหว่าง PG15 และ PG16 และยกตัวอย่างสิ่งที่เปลี่ยนไป

การปรับปรุง 10 ประการของตัววางแผนคิวรีใน PostgreSQL 16

  • Incremental Sort: Incremental Sort ซึ่งถูกนำมาใช้ครั้งแรกใน PostgreSQL 13 จะใช้ประโยชน์จากกรณีที่ชุดผลลัพธ์บางส่วนถูกจัดเรียงตามคอลัมน์นำหน้าอย่างน้อยหนึ่งคอลัมน์อยู่แล้ว เพื่อทำการจัดเรียงเฉพาะคอลัมน์ที่เหลือ
  • Aggregates with Presorted Data: ตัววางแผนคิวรีของ PostgreSQL 16 พยายามสร้างแผนที่ป้อนแถวให้กับโหนด aggregate ตามลำดับที่จัดเรียงไว้แล้ว
  • Memoize: โหนดแผน Memoize ซึ่งถูกนำมาใช้ครั้งแรกใน PostgreSQL 14 ทำงานเป็นชั้นแคชเพื่อหลีกเลี่ยงการค้นหาค่าซ้ำ
  • Anti Join: PostgreSQL 16 ทำให้สามารถแฮชตารางที่มีขนาดเล็กกว่าได้เมื่อทำ anti join
  • Parallel Hash Join: PostgreSQL 16 รองรับ parallel hash join สำหรับชนิดการ join แบบ FULL และ RIGHT
  • Window Function Optimization: PostgreSQL 16 สามารถใช้ window function ที่เร็วกว่าได้เมื่อใช้โหมด ROWS เทียบกับโหมด RANGE
  • Optimizations for Monotonic Window Functions: PostgreSQL 16 ขยายการเพิ่มประสิทธิภาพสำหรับ window function เช่น ntile(), cume_dist(), percent_rank()
  • Join Removal on Partitioned Tables: PostgreSQL 16 อนุญาตให้ใช้การเพิ่มประสิทธิภาพแบบลบ LEFT JOIN บนตารางพาร์ทิชัน
  • Using Limit for DISTINCT Queries: ตัววางแผนคิวรีของ PostgreSQL 16 จะไม่ใส่โหนดแผนสำหรับลบค่าซ้ำในผลลัพธ์ หากสามารถตรวจจับได้ว่าทุกแถวมีค่าเดียวกัน
  • Relaxed Rules for Merge Join: ตัววางแผนคิวรีของ PostgreSQL 16 เมื่อต้องพิจารณา Merge Join จะตรวจสอบว่าอย่างน้อยหนึ่งคอลัมน์นำหน้าถูกจัดเรียงอย่างถูกต้อง แทนที่จะต้องให้ลำดับของแถวตรงกันอย่างสมบูรณ์

ความเห็นของ GN⁺

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

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

1 ความคิดเห็น

 
GN⁺ 2024-02-11
ความคิดเห็นจาก Hacker News
  • มีความเห็นว่าคงจะดีถ้า query planner ของ Postgres สามารถวางแผนคิวรีใหม่ระหว่างการรันได้ เพราะเมื่อมีข้อมูลเกี่ยวกับการกระจายตัวของข้อมูลไม่เพียงพอ ก็อาจสร้างแผนคิวรีที่ไม่มีประสิทธิภาพและส่งผลอย่างมากต่อเวลาในการรันได้ หากคิวรีทำงานช้ากว่าที่คาด ก็ควรมีความสามารถในการวางแผนคิวรีใหม่โดยอิงจากข้อมูลความคืบหน้าปัจจุบัน อย่างไรก็ตาม เนื่องจาก Postgres รองรับสตรีมมิงคิวรี การเปลี่ยนแผนระหว่างการรันจึงต้องอาศัยการเปลี่ยนแปลงโครงสร้างพื้นฐานค่อนข้างมาก
  • มีผู้ใช้รายหนึ่งบอกว่าใช้ explain.dalibo.com และ www.pgexplain.dev เป็นเครื่องมือสำหรับแสดงภาพคิวรี โดยทั้งสองเครื่องมือให้ผลลัพธ์ที่คล้ายกัน
  • มีความเห็นว่าการปรับปรุง query planner เป็นส่วนสำคัญของฐานข้อมูล แต่โดยมากจะสังเกตเห็นก็ต่อเมื่อมันไม่ทำงานอย่างที่ต้องการ พร้อมแชร์ประสบการณ์ว่า JIT (Just-In-Time) compiler ใน Postgres เวอร์ชันใหม่ ๆ ดูเหมือนจะมี heuristic ณ เวลาที่ใช้งานซึ่งยังไม่แข็งแรงพอ และอาจทำให้ข้อมูลขนาดเล็กช้าลง จึงแนะนำให้ปิด JIT
  • มีความเห็นว่าสงสัยว่าการเปลี่ยนแปลงต่าง ๆ มีผลจริงบ่อยแค่ไหนกับคิวรีจริง โดยเฉพาะการเปลี่ยนแปลงประเภท "ใช้ Limit แทน DISTINCT เมื่อเป็นไปได้" ว่ามีกรณีที่ถูกนำไปใช้จริงหรือไม่ และตั้งคำถามว่านักพัฒนา Postgres มีข้อมูลเรื่องนี้หรือไม่
  • มีความเห็นว่าอยากให้มี "strict mode" สำหรับการทดสอบแอปพลิเคชัน ซึ่งในโหมดนี้หากไม่มีดัชนีที่ช่วยปรับปรุงคิวรีได้ก็จะคืนข้อผิดพลาด และสามารถสร้างดัชนีที่จำเป็นได้ผ่านคำสั่ง CREATE INDICES FOR <sql> นอกจากนี้ยังมีข้อเสนอเรื่องโหมดสร้างดัชนีอัตโนมัติสำหรับการพัฒนาและการใช้งานแบบโต้ตอบ
  • เพื่อนของผู้ใช้รายหนึ่งทำงานเป็น Microsoft DBA ให้กับธุรกิจขนาดเล็กและกลาง และอ้างว่าไม่สามารถทำงานจริงจังด้วย Postgres ได้ อีกทั้งยังบอกว่าตกใจที่ Postgres ไม่มี query planner ซึ่งเป็นข้อมูลที่ไม่ถูกต้อง จึงมีคำถามว่าคำกล่าวอ้างที่ว่า MSSQL รองรับงานขนาดใหญ่ได้ดีกว่า Postgres นั้นน่าเชื่อถือเพียงใด
  • มีการตั้งคำถามว่าทำไม Postgres จึงไม่ implement hints
  • มีคำถามว่าฟีเจอร์ที่ Citus Data ประกาศนั้นทำไมถึงเผยแพร่จากที่อื่นแทนที่จะเป็น postgresql.org และเป็นฟีเจอร์แบบเสียเงินหรือเป็นส่วนขยายโอเพนซอร์ส
  • มีคำถามว่าเมื่อใดที่ Postgres จะสามารถใช้ดัชนีเพื่อเร่งคิวรี IS NOT DISTINCT FROM ได้
  • มีความคิดเห็นหนึ่งถูกแจ้งและถูกทำเครื่องหมาย (flagged) ไว้