On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company