On Sat, Jan 15, 2011 at 6:28 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> If the problem is that all the freezing happens at once, then ISTM the
>> solution is to add a random factor. Say, when a tuple just passes the
>> lower threshold it has a 1% chance of being frozen. The chance grows
>> until it is 100% as it reaches the upper threshold.
>
> Doesn't have to be random; it could be determinative. That is, we could
> have a vacuum_freeze_max_size parameter ... and accompanying autovacuum
> parameter ... which allowed the user to limit freezing scans to, say,
> 1GB of the table at a time. If I could, say, call a manual freeze of
> 10% of the largest tables ever night, then I might actually be able to
> schedule it. It's a full scan of the whole table which is fatal.
I think this is worth pursuing at some point, though of course one
needs to devise an algorithm that spreads out the freezing enough but
not too much. But it's fairly off-topic from the original subject of
this thread, which was a quick-and-dirty attempt to limit the amount
of I/O caused by hint bits. I'm still very interested in knowing what
people think about that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company