In this post, I am sharing a system view which we can use to check the progress of running vacuum process of PostgreSQL.

PostgreSQL based on MVCC, and in this architecture VACUUM is a routine task of DBA for removing dead tuples.

What is Multi Version Concurrency Control (MVCC)

Now the question is, How to monitor the progress of VACUUM?

Simple, we can use pg_stat_progress_vacuum view for this purpose. In this view, we can check phase column which indicates the different stages of running the vacuum.

select * from pg_stat_progress_vacuum

Type of phases:

initializing: VACUUM is preparing to begin scanning the heap
scanning heap: VACUUM is currently scanning the heap
vacuuming indexes: VACUUM is currently vacuuming the indexes
vacuuming heap: VACUUM is currently vacuuming the heap
cleaning up indexes: VACUUM is currently cleaning up indexes
truncating heap: VACUUM is currently truncating the heap to return empty pages at the end of the relation to the operating system
performing final cleanup: VACUUM is performing final cleanup. During this phase, VACUUM will vacuum the free space map, update statistics in pg_class, and report statistics to the statistics collector

PostgreSQL: What is a Free Space Map (FSM)?

Reference taken from the official page:

PostgreSQL stores relation information in a separate file by using OID. You can find a list of those files in the PostgreSQL data directory.

It creates a file for relation like table, index, sequence and toast table. As it stores with OID (Object ID), then it’s hard to locate a particular relation file.

Once you get the OID and location of your table, you can quickly estimate other items like a size of a table, FSM file, VM file, toast information.

You can access few related articles:
What is FSM?
What is VM?
What is toast?

Use pg_relation_filepath() to get a location of your table:

SELECT *FROM pg_relation_filepath('Table_Name')

In this post, sharing a small note on one of the internal architecture things of PostgreSQL.

Each Table and Index has an FSM which used to keep track of available space in the relation.

It stores all free space related information in an alongside primary relation and that relation starts with the file node number plus the suffix _fsm.

If you do not know about the MVCC (Multiversion Concurrency Control), please visit below an article.

What is Multi Version Concurrency Control (MVCC)

Because of MVCC architecture, PostgreSQL generates dead tuples on each update and delete action.

Why VACUUM requires in MVCC because VACUUM removes dead row versions in tables and marks the space available for future reuse.

The VACUUM process also updates the Free Space Map and using VACUUM FULL we can recover those free spaces.

The FSM pages are organized as a tree.
The bottom level FSM pages store the free space available on each page, using one byte to represent each such page.
The upper levels aggregate information from the lower levels.

We can also examine free space pages using pg_freespace module.

CREATE EXTENSION pg_freespace;
SELECT * FROM pg_freespace('table_name');