From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatic free space map filling |
Date: | 2006-03-02 15:58:57 |
Message-ID: | 3176.1141315137@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> What is unclear to me in the discussion is whether or not this is
> invalidating the item on the TODO list...
No, I don't think any of this is an argument against the
dirty-page-bitmap idea. The amount of foreground effort needed to set a
dirty-page bit is minimal (maybe even zero, if we can make the bgwriter
do it, though I'm pretty suspicious of that idea because I think it
needs to be done immediately when the page is dirtied). I don't see the
dirty-page bitmap as changing the way that VACUUM works in any
fundamental respect --- it will just allow the vacuum process to skip
reading pages that certainly don't need to change.
One point that does need to be considered though is what about
anti-wraparound processing (ie, replacing old XIDs with FrozenXID before
they wrap around)? VACUUM currently is a safe way to handle that,
but if its normal mode of operation stops looking at every tuple then
we're going to have an issue there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-03-02 16:04:38 | Re: pg_config --pgxs |
Previous Message | Jonah H. Harris | 2006-03-02 15:19:51 | Re: 8.2 Feature Freeze Rough Estimate |