Re: Idea for getting rid of VACUUM FREEZE on cold pages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date
Msg-id 9200.1275501931@sss.pgh.pa.us
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Keepalive for max_standby_delay
Next
From: Robert Haas
Date:
Subject: Re: Keepalive for max_standby_delay