| Lists: | pgsql-patches |
|---|
| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | pgsql-patches(at)postgresql(dot)org |
| Subject: | Dead Space Map patch |
| Date: | 2006-12-28 06:14:56 |
| Message-ID: | 20061228142827.5FBF.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
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
| Attachment | Content-Type | Size |
|---|---|---|
| deadspacemap.patch.gz | application/octet-stream | 25.3 KB |
| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Cc: | <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Dead Space Map patch |
| Date: | 2006-12-28 19:40:30 |
| Message-ID: | 1167334830.3633.177.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-patches |
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