PostgreSQL Index Advisor

 (github.com/supabase)
16 คะแนน โดย xguru 2024-04-15 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ส่วนขยาย PostgreSQL โดย Supabse ที่แนะนำดัชนีเพื่อปรับปรุงประสิทธิภาพของคิวรี
  • เมื่อส่งคิวรีให้ฟังก์ชัน index_advisor() จะคืนค่าต้นทุนก่อน/หลังสำหรับการสแกนแบบสตาร์ทอัป/ทั้งหมด และ SQL DDL สำหรับสร้างดัชนี
    • การใช้งาน: select * from index_advisor('select book.id from book where title = $1');
    • ค่าที่คืน: {"CREATE INDEX ON public.book USING btree (title)"}
  • สำหรับคิวรีที่ซับซ้อน อาจคืนคำสั่งสร้างดัชนีหลายรายการ
  • รองรับ generic parameter ($1, $2, ..)
  • รองรับ Materialized View
  • สามารถระบุตาราง/คอลัมน์ที่ถูกซ่อนอยู่โดย view ได้

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

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

 
savvykang 2024-04-15

เวอร์ชันปัจจุบันแนะนำได้เฉพาะดัชนี btree แบบคอลัมน์เดียวเท่านั้น หากเงื่อนไขการค้นหาซับซ้อนขึ้นหรือกำลังใช้การค้นหาแบบ full text ก็จะไม่สามารถใช้งานได้ https://supabase.com/docs/guides/…
 
savvykang 2024-04-16

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

https://www.postgresql.org/docs/current/indexes-bitmap-scans.html
 
xguru 2024-04-15

ความเห็นจาก Hacker News

  • น่าจะดีถ้ามีฟีเจอร์ที่แนะนำ data type ที่มีประสิทธิภาพมากกว่านี้โดยอิงจากข้อมูลที่ถูกเก็บจริงในตาราง
  • อยากได้ฐานข้อมูลที่ตรวจจับ query ช้าได้อัตโนมัติและสร้าง index ที่จำเป็นให้เอง
    • เมื่อรัน load test จากแอปพลิเคชัน ก็ให้ฐานข้อมูลรับการเรียก เก็บรวบรวม query แล้วปรับจูนตัวเองโดยอัตโนมัติ
  • ไม่เคยรู้มาก่อนว่า HypoPG ใช้งานบน RDS ได้มานานกว่าหนึ่งปีแล้ว
  • ใน join ที่มีมากกว่า 3 ตัว อยากให้มีการใช้ index กับ relation หนึ่ง แต่ถ้าไม่ใส่ limit ให้ CTE, Postgres จะพยายามรันแต่ละ join แบบขนานและพยายาม join แถวจำนวนมหาศาล
    • ช่วงนี้การรับมือกับ query planner ทำให้รู้สึกเหมือนจะเลิกใช้ pg แล้ว
  • CockroachDB มีความสามารถคล้ายกันแบบ built-in
    • มันจะดึง query ช้าที่มีอยู่มาวิเคราะห์ virtual index และเสนอแนะเพื่อให้ได้ query plan ที่ดีกว่า
    • เพิ่มได้จากคอนโซล UI ด้วยการคลิกครั้งเดียว
  • ใน distributed query engine อย่าง Presto หรือ Spark จะใช้ partition และ bucket แทน index เพื่อทำงานลักษณะคล้ายกัน
    • วิธีนี้ช่วยลดการคำนวณ เวลา และค่าใช้จ่ายได้
  • เขียนด้วย Vanilla Pl/PgSQL จึงใช้งานสะดวก
    • มีความอยากจะคัดลอกฟังก์ชัน index_advisor(text) เข้าไปใน session แล้วเริ่ม hardcode กับ heuristic ทันที
    • extension ที่มีความหมายจริง ๆ ส่วนใหญ่ต้อง compile, install, create และ drop
  • คล้ายกับ TiAdvisor ของ TiDB และใช้วิธีแบบ virtual
  • กำลังใช้ pghero อยู่ และมันมีฟีเจอร์นี้ผ่าน GUI
  • ดูเหมือนจะไม่ได้ให้การพิจารณาหรือ insight เกี่ยวกับ trade-off ที่เกี่ยวข้อง
    • extension พื้นฐานอย่าง HypoPG ดูเหมือนจะไม่ได้เก็บสถิติของข้อมูลที่มีผลต่อ query planner
  • สงสัยว่ามันรับรู้ parent table และ child table ที่สืบทอดมาหรือไม่