Skip to main content

PostgreSQL Vacuum and Vacuum full are not two different processes

 PostgreSQL’s VACUUM and VACUUM FULL are not separate processes but rather different operational modes of the same maintenance command. Here’s why:

Core Implementation

Both commands share the same underlying codebase and are executed through the vacuum_rel() function in PostgreSQL’s source code (src/backend/commands/vacuum.c). The key distinction lies in the FULL option, which triggers additional steps:

  • Standard VACUUM:
    • Removes dead tuples (obsolete rows) and marks space reusable within PostgreSQL
    • Updates the visibility map to optimize future queries
    • Runs concurrently with read/write operations
  • VACUUM FULL:
    • Rewrites the entire table into a new disk file, compressing it and reclaiming space for the operating system
    • Rebuilds all indexes and requires an ACCESS EXCLUSIVE lock, blocking other operations

Key Differences in Behavior

AspectStandard VACUUMVACUUM FULL
Space ReclamationInternal reuse onlyOS-level space release
LockingNon-blockingFull table lock
Performance ImpactLightweight, incrementalHeavy, resource-intensive
Use CaseRoutine maintenanceSevere table bloat remediation

 

Why They Aren’t Separate Processes

  • Shared Code Path: Both use the same core logic for dead-tuple identification and cleanup. VACUUM FULL adds a table-rewrite step by calling cluster_rel()
  • Configuration Integration: Parameters like autovacuum_vacuum_scale_factor apply to both, and autovacuum workers handle standard VACUUM by default
  • Unified Command Structure: The FULL option is a modifier rather than a standalone tool, as seen in the SQL syntax:

When to Use Each

  • Standard VACUUM: Daily maintenance to prevent bloat from MVCC dead tuples
  • VACUUM FULL: Rarely, for extreme cases where table size has grown uncontrollably due to long-unvacuumed updates/deletes

In summary, while their outcomes differ significantly, VACUUM and VACUUM FULL are part of a single maintenance framework, differentiated primarily by the aggressiveness of space reclamation and locking behavior.

Comments

  1. Very Useful blog for health checks, thanks for sharing

    ReplyDelete

Post a Comment

Popular posts from this blog

Job scheduler for PostgreSQL "pg_cron"

What is pg_cron   : -   pg_cron is a simple cron-based job scheduler for   PostgreSQL (9.5 or higher)   that runs inside the database as an extension. It uses the same syntax as regular cron, but it allows you to schedule PostgreSQL commands directly from the database . Why We need it ? Running periodic maintenance jobs or removing old data is a common requirement in PostgreSQL. A simple way to achieve this is to configure cron or another external daemon to periodically connect to the database and run a command. Let's see how it's works  Step 1 :-  For implementing/Installation of pg_cron you need to download source code from git Dowload link  export PATH=/usr/local/pgsql/bin:$PATH wget https://github.com/citusdata/pg_cron/archive/master.zip unzip master cd pg_cron-master/ make make install    Step 2 : - To start the pg_cron background worker when PostgreSQL starts, you need to add pg_cron to  shared_preload_libraries   in post...

PostgreSQL Health Check - Performance Audit and Recommendations

   PostgreSQL Server Capacity Planning and Optimization: Conduct a thorough assessment of current and projected workload demands on the database server's critical resources. This evaluation should cover key factors such as CPU utilization, RAM consumption, storage requirements, I/O performance, and network bandwidth usage. Consider both short-term fluctuations and long-term usage patterns to accurately forecast future needs and potential bottlenecks. Collect and analyze performance metrics over extended periods, including peak and off-peak hours, to gain a comprehensive understanding of server behavior. Use appropriate monitoring tools to gather detailed data on query execution times, resource utilization patterns, and system responsiveness under varying loads. Identify recurring performance issues, resource contention points, or capacity limitations that may affect the overall efficiency of the PostgreSQL environment. Based on this analysis, develop actionable recommendations...