DSM WIP patch version 2

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-patches(at)postgresql(dot)org
Subject: DSM WIP patch version 2
Date: 2007-03-01 12:06:53
Message-ID: 20070301193816.5EB5.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

The attached is a WIP DSM patch.

I make an attempt to track all of unfrozen and dead tuples in 100% accuracy
in this patch. However, it is still an open issue; There is another opinion
that DSM should be used as just a hint for vacuum. We'll discuss further the
design in that what's the best for 8.3 and/or for the future.

Next step of DSM is to cooperate with the background writer. I'm drawing up
that DSM is marked pages as LOW priority to vacuum at first, and bgwriter
upgrades the state to HIGH priority if there are many dead tuples in them
just before writing out.

SQL changes
-----------

- VACUUM ALL : Vacuum without DSM. Scans all pages.
- VACUUM : Vacuum with DSM.

GUC changes
-----------

# - Free Space Map & Dead Space Map -

tracked_relations = 1000
Replacement of max_fsm_relations. It is used by FSM and DSM.

tracked_freespaces = 2GB
Replacement of max_fsm_pages. Same meaning but can be set in bytes.

tracked_deadspaces = 8GB
The maximum number of size for which dead space is tracked.
It might be better to be scaled with whole database size.

tracked_minimum_relation = 8MB
The minimum size of tables of which dead space is tracked.

How to examine DSM
------------------

contrib/pg_deadspacemap (included in the patch) would help you. This shows
the contents of dead space map. See also README.pg_deadspacemap.

contrib/pg_heapdump can be used to read all tuples in a heap.
You can retrieve deleted tuples regardless of the MVCC snapshot.

The below is an example that shows DSM is tracking all of the unfrozen
and dead tuples.

# SELECT * FROM pg_deadspacemap;
relid | schemaname | relname | high | low | unfrozen | frozen | status
-------+------------+---------+------+-----+----------+--------+--------
1255 | pg_catalog | pg_proc | 1 | 0 | 1 | 48 | full
(1 row)

# select * from pg_deadspacemap('pg_proc');
pg_deadspacemap
-----------------
47
49
(2 rows)

# select * from pg_heapdump('pg_proc') where xmin > 2 OR xmax IS NOT NULL;
blknum | offnum | itemoff | itemlen | xmin | cmin | xmax | cmax | infomask
--------+--------+---------+---------+------+------+------+------+----------
47 | 25 | 936 | 419 | 914 | | | | 2323
47 | 26 | 512 | 419 | 915 | | | | 2323
49 | 1 | 5328 | 207 | 1161 | | 1161 | | 51
49 | 2 | 5112 | 211 | 1161 | | 1161 | | 51
49 | 3 | 4864 | 244 | 1161 | | | | 10259
49 | 4 | 4616 | 248 | 1161 | | | | 10259
(6 rows)

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

Attachment Content-Type Size
pg_heapdump.tar.gz application/octet-stream 3.3 KB
deadspacemap-v2.patch.gz application/octet-stream 42.2 KB

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-03-01 13:35:21 Re: lo_truncate
Previous Message Simon Riggs 2007-03-01 09:00:33 Re: Fast COPY after TRUNCATE bug and fix