Skip site navigation (1) Skip section navigation (2)

Re: Quick idea for reducing VACUUM contention

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quick idea for reducing VACUUM contention
Date: 2007-07-27 01:17:45
Message-ID: 20070727093115.6267.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
"Simon Riggs" <simon(at)2ndquadrant(dot)com> wrote:

> Read the heap blocks in sequence, but make a conditional lock for
> cleanup on each block. If we don't get it, sleep, then try again when we
> wake up. If we fail the second time, just skip the block completely.

When we allow some skips in removing dead tuples, can we guarantee
pg_class.relfrozenxid? I think we might need additional "freezing-xmax"
operations to avoid XID-wraparound in the first path of vacuum, though
it hardly occurs.


It might be a future topic ... if we are in the direciton of 
"optimistic sweeping", is it possible to remove the second path of vacuum
completely? We just add XID of the vacuum to dead tuples we see in the
first path. When backends find a dead tuple and see the transaction
identified by XID in it has commited, they can freely reuse the area of
the dead tuple because we can assume index entries pointing the tuple
have been removed by the vacuum. We would use the infrastructure
introduced by HOT for this purpose.

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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-07-27 02:37:45
Subject: LSN grouping within clog pages
Previous:From: Tom LaneDate: 2007-07-27 00:43:45
Subject: Re: stats_block_level

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group