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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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