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
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 |