Re: Quick idea for reducing VACUUM contention - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: Quick idea for reducing VACUUM contention
Date
Msg-id 20070727093115.6267.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Quick idea for reducing VACUUM contention  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Quick idea for reducing VACUUM contention  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: stats_block_level
Next
From: Tom Lane
Date:
Subject: LSN grouping within clog pages