Thread: Dead Space Map patch

This is a patch for TODO item:
| Create a bitmap of pages that need vacuuming

Dead Space Map allows VACUUM to scan only pages that need vacuuming.
I sent to HACKERS the description of this patch.
Comments, suggestions and evaluation reports are welcome.

Usage of the feature is below:

- VACUUM FREEZE is recommended.
    Pages that need vacuuming and freezing are not separated in the patch.
    If we do non-FREEZE VACUUM, next VACUUM will also read pages that we
    cannot freeze all of tuples in it at the last VACUUM. It's a waste.

- [GUC] dsm_buffers (integer)
    The used memory size in dead space map. Default is 16MB,
    that can track maximum 1TB of heap tables.

- [GUC] dsm_vacuum (boolean)
    This enables the dead space map in VACUUM. Default is on.
    Even if it is off, DSM are always recorded and updated.

- contrib/pg_deadspacemap
    This shows the contents of dead space map.
    See also README.pg_deadspacemap.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

On Thu, 2006-12-28 at 15:14 +0900, ITAGAKI Takahiro wrote:
> Even if it is off, DSM are always recorded and updated.

The purpose of the patch, as I understand it, is performance.

Can I ask what the performance overhead of this is for standard OLTP
workloads?

Do you have some performance numbers for VACUUM with/without this patch?
Presumably it does speed things up considerably, but question is, how
much?

Is there a point where you VACUUM more than x% of a table that it is
actually better to just VACUUM the whole thing, because of readahead?

Is there a size of table for which keeps dsm information is not
worthwhile? i.e. small tables

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com