ตารางที่ลบข้อมูลเก่าออกไปมากอาจยังมีไฟล์ขนาดใกล้เดิม พอเปิดดูดิสก์แล้วพื้นที่ไม่เพิ่ม จึงเกิดคำถามว่า DELETE ทำงานจริงหรือฐานเก็บข้อมูลที่ลบไปไว้โดยไม่จำเป็น
PostgreSQL ใช้แนวคิดหลายรุ่นของข้อมูลเพื่อให้ transaction ทำงานร่วมกันได้ รุ่นที่ถูกแก้หรือลบจึงไม่ได้หายจากไฟล์ทันที เพราะอาจยังมีผู้อ่านที่ต้องเห็นข้อมูลตาม snapshot ของตัวเอง
คำถามเรื่องพื้นที่จึงต้องแยกว่าอยากให้ฐานนำพื้นที่กลับมาใช้ หรืออยากให้ไฟล์เล็กลงจนคืนพื้นที่ให้ระบบปฏิบัติการครับ สองเป้าหมายนี้ใช้หลักฐานกับต้นทุนต่างกัน
การลบที่ commit แล้วทำให้ transaction ใหม่อ่านข้อมูลตามกติกาการมองเห็นที่เปลี่ยนไป แต่ไม่ได้บังคับให้ PostgreSQL อัดแถวทั้งหมดที่เหลือใหม่และย่อไฟล์ทุกครั้ง การทำเช่นนั้นกับทุกการเปลี่ยนจะมีต้นทุนสูงและขัดกับการให้ผู้อ่านหลายชุดทำงานร่วมกัน
UPDATE ก็มีเรื่องรุ่นข้อมูลเก่าเช่นกัน แม้จำนวนแถวที่คนใช้งานเห็นแทบไม่เพิ่ม ตารางที่แก้บ่อยยังต้องมีการดูแลพื้นที่จากรุ่นเก่าตามวงจรของ MVCC ไม่มองเฉพาะจำนวนแถวที่ SELECT นับได้แล้วคาดว่าขนาดไฟล์ควรคงที่เสมอ
รุ่นเก่าจะเก็บกวาดได้เมื่อไม่จำเป็นต่อ transaction ที่เกี่ยวข้องตามกติกา หากยังมี snapshot ที่ต้องใช้ การรีบลบทิ้งย่อมทำให้ผู้อ่านนั้นเห็นข้อมูลไม่ตรงสัญญา การรอความปลอดภัยจึงเป็นส่วนหนึ่งของความถูกต้อง ไม่ใช่เพียงงานทำความสะอาดที่ข้ามได้ตามใจ
VACUUM ปกติช่วยนำพื้นที่ของ dead row versions ที่เก็บกวาดได้กลับมารองรับข้อมูลใหม่ในตารางและ index ตามกระบวนการ จึงอาจช่วยให้การเติบโตช้าลงโดยที่ยอดขนาดไฟล์จากระบบปฏิบัติการไม่ได้ลดลงให้เห็นทันที
มีกรณีที่หน้าท้ายตารางว่างและตัดคืนได้ตามเงื่อนไขของระบบ แต่ไม่ควรใช้ข้อยกเว้นนี้เป็นคำสัญญาว่าทุกรอบ VACUUM จะคืนพื้นที่ทั้งหมดให้ดิสก์ การตรวจควรมองทั้งพื้นที่ใช้ซ้ำกับแนวโน้มเติบโต ไม่ดูเลขไฟล์เพียงตัวเดียว
ถ้าตารางจะมีการเขียนเพิ่มกลับมาในขนาดใกล้เดิม พื้นที่ว่างภายในที่ใช้ซ้ำได้อาจเป็นส่วนของการทำงานตามปกติ การพยายามย่อให้เล็กที่สุดทุกวันแล้วปล่อยให้โตใหม่อาจเพิ่มภาระโดยไม่ได้ตอบความต้องการของบริการ
เป้าหมายของการดูแลตามรอบจึงควรเป็นการเก็บกวาดได้ทันภาระและรักษาพื้นที่ใช้งานให้พอ ไม่ใช่ไล่ให้ไฟล์มีขนาดต่ำสุดตลอดเวลาโดยยังไม่ประเมินอัตราแก้ข้อมูลกับทรัพยากรที่มี
VACUUM FULL ต่างจากการเก็บกวาดปกติ เพราะเขียนตารางฉบับใหม่ที่กระชับกว่าแล้วค่อยจัดการชุดเดิม กระบวนการนี้ใช้เวลาและพื้นที่เพิ่มระหว่างทำ พร้อมต้องใช้ lock ที่ขัดกับการใช้งานตารางตามที่เอกสารกำหนด
จึงไม่ควรเห็นดิสก์ใกล้เต็มแล้วเรียก FULL โดยยังไม่ประเมินว่ามีพื้นที่ทำสำเนาใหม่พอหรือไม่ การที่คำสั่งมีชื่อเหมือนวิธีแก้พื้นที่ไม่ได้ทำให้มันเป็นงานเบาซึ่งรันได้ในทุกสถานการณ์
นอกจากขนาดตาราง ต้องคิดถึง index ระยะที่คำขอใช้งานจะรอ และภาระของระบบที่เกี่ยวข้องด้วย ควรทดลองกับชุดที่มีลักษณะใกล้เคียงในสภาพแวดล้อมแยก พร้อมเตรียมสำรองและทางรับมือหากใช้เวลาต่างจากที่คาด
Autovacuum ไม่ได้เรียก VACUUM FULL ให้เอง การปล่อยให้ระบบเก็บกวาดอัตโนมัติจึงไม่ได้มีความหมายว่าจะย่อตารางทุกครั้งหรือเปลี่ยนไปเป็นงาน rewrite โดยไม่ต้องวางแผน
ควรตรวจอายุ transaction กับ snapshot ที่เกี่ยวข้องเมื่อมีรุ่นข้อมูลค้างมาก ไม่ดูเฉพาะว่ามี autovacuum process ทำงานอยู่แล้วหรือไม่ หากยังมีผู้อ่านที่จำเป็นต้องใช้ข้อมูลเก่า การเพิ่มความถี่อย่างเดียวก็ไม่ได้ทำให้กติกาการมองเห็นเปลี่ยน
สถานะ idle in transaction เป็นจุดหนึ่งที่ต้องตาม เพราะ connection อาจไม่ได้รัน query แต่ยังเปิด transaction อยู่ การแก้ต้องกลับไปที่เจ้าของและขอบเขตการทำงานของแอป ไม่ยุติ session ทุกตัวที่อายุยาวโดยไม่รู้ว่ากำลังทำอะไร
หากมี standby หรือการเก็บสถานะเพื่อ replication ต้องตรวจนโยบายที่เกี่ยวข้องตามสถาปัตยกรรมด้วย ไม่ปิดกลไกที่ตั้งใจรักษาความสอดคล้องเพียงเพื่อให้จำนวน dead tuples ลด โดยยังไม่เข้าใจผลต่อการอ่านหรือการกู้ข้อมูล
เรื่องนี้เชื่อมกับการออกแบบแอปโดยตรง งานที่เปิด transaction รอผู้ใช้หรือ network นานเกินไปอาจมีต้นทุนทั้ง lock และการรักษารุ่นข้อมูล จึงควรแยกงานที่ไม่จำเป็นต้องอยู่ในขอบเขตฐานออกมาตามสัญญาที่เหมาะสม
ANALYZE เก็บสถิติให้ planner ประเมินลักษณะข้อมูลและเลือกแผน query ส่วน VACUUM มีงานเก็บกวาดกับหน้าที่ดูแลภายในอื่นตามระบบ การเห็น query เร็วขึ้นหลังปรับสถิติจึงไม่ใช่หลักฐานว่าไฟล์ตารางถูกย่อแล้ว
ทั้งสองงานอาจถูกจัดให้ทำร่วมกันหรือเริ่มจากระบบอัตโนมัติได้ แต่ต้องอ่านผลตามหน้าที่ของมัน เมื่อเปลี่ยนข้อมูลมากควรตรวจว่าสถิติที่ planner ใช้ยังเหมาะสมหรือไม่ โดยไม่สรุปว่าทุกอาการช้าเกิดจากไฟล์ใหญ่
ข้อมูลอย่าง n_dead_tup ในสถิติของตารางเป็นค่าประมาณ ไม่ใช่การนับทุกชิ้นพื้นที่ที่คืนได้แน่นอน ควรดูร่วมกับประวัติ vacuum ขนาดตารางกับ index และอัตราการเปลี่ยนตามช่วงเวลา ก่อนตั้งข้อสรุปว่ามี bloat เท่าไรหรือจะคืนได้กี่ byte
ถ้าข้อมูลมีอายุแน่นอนและลบเป็นช่วงใหญ่ประจำ ควรทบทวนโครงสร้างเก็บกับกระบวนการ retention ตามความต้องการจริง การเลือกรูปแบบตารางหรือแบ่งข้อมูลอาจช่วยให้จัดวงจรได้ชัด แต่ก็มีผลต่อ query constraint และงานดูแลที่ต้องประเมินก่อน
การเฝ้าระวังควรบอกได้ว่าพื้นที่โตจากอะไร มีงานเก็บกวาดตามทันหรือไม่ และเหลืองบสำหรับ maintenance เท่าไร ไม่รอให้พื้นที่เต็มแล้วค่อยเลือกคำสั่งที่ชื่อดูเหมือนช่วยที่สุด ทั้งยังไม่ควรลบไฟล์ฐานจากด้านนอกเพื่อย่อพื้นที่เอง
การลบข้อมูลใน PostgreSQL กับการคืนพื้นที่ดิสก์เป็นคนละขั้น VACUUM ปกติช่วยให้พื้นที่เก่าถูกใช้ใหม่ ส่วนงาน rewrite เพื่อย่อไฟล์ต้องมีงบพื้นที่ เวลาและ lock เมื่อดูอายุ transaction สถิติและรูปแบบการเปลี่ยนข้อมูลร่วมกัน เราจะเลือกวิธีดูแลให้ตรงเป้าหมาย โดยรักษาทั้งพื้นที่สำรองและความถูกต้องของผู้อ่านที่ยังทำงานอยู่