| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: limiting hint bit I/O |
| Date: | 2011-01-15 23:28:25 |
| Message-ID: | 4D322D99.60809@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2011-01-15 23:54:10 | Re: Include WAL in base backup |
| Previous Message | Josh Berkus | 2011-01-15 23:20:57 | Re: LAST CALL FOR 9.1 |