On 6/2/2010 2:16 PM, Robert Haas wrote:
> 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.
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
