Re: Idea for getting rid of VACUUM FREEZE on cold pages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date: 2010-05-23 01:16:57
Message-ID: 7319.1274577417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Somebody (I think Joe or Heikki) poked a big hole in this last night at
>> the Royal Oak. Although the scheme would get rid of the need to replace
>> old XIDs with FrozenXid, it does not get rid of the need to set hint
>> bits before you can truncate CLOG. So in your example of an insert-only
>> table that's probably never read again, there's still a minimum of one
>> update visit required on every old page. Now that's still better than
>> two update visits ... but we could manage that already, just by tweaking
>> vacuum's heuristics about when to freeze vs when to set hint bits.

> Yeah, someone pointed that out to me too and suggested that a freeze map
> was the better solution. I still think there's something we can do with
> pages on the visibility map but I'll have to think about it some more.

It occurred to me on the flight home that maybe we could salvage
something from this if there were some mechanism that caused hint bits
to get set before the page got written out from shared buffers the first
time. This assumes that you have enough slack in shared-buffer space
that the transactions that touched a particular page all commit or abort
before the page first gets flushed to disk.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mohammad Heykal Abdillah 2010-05-23 01:33:08 Re: "unexpected" query behaviour after i change parser code
Previous Message Jan Wieck 2010-05-23 00:52:25 Re: Idea for getting rid of VACUUM FREEZE on cold pages