On 6/2/2010 2:16 PM, Robert Haas wrote:
On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvhe...@commandprompt.com> writes:
The problem is that vacuum doesn't know that a certain part of the table
is already frozen. It needs to scan it completely anyways. If we had a
"frozen" map, we could mark pages that are completely frozen and thus do
not need any vacuuming; but we don't (I don't recall the reasons for
this. Maybe it's just that no one has gotten around to it, or maybe
there's something else).
Offhand I think the reason is that you'd have to trust the frozen bit
to be 100% correct (or at least never set to 1 in error). Currently,
both the FSM and visibility forks are just hints, and we won't suffer
data corruption if they're wrong; so we don't get too tense about WAL
logging or fsync'ing updates. I believe Heikki is looking into what
it'd take to make the visibility map 100% reliable, in connection with
the desire for index-only scans. If we get that and the overhead isn't
too terrible maybe we could build a frozen-status map the same way.
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both purposes. Keeping around the old xmin values after every tuple
on the page is visible to every running transaction is useful only for
forensics, and building a whole new freeze map just to retain that
information longer (and eventually force a massive anti-wraparound
vacuum) seems like overkill.
Agreed.
The whole business of minimum freeze age always struck me as leaving
bread crumbs behind. Other than forensics, what is the actual value of
that overhead?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
