Hi, Jim,
Jim C. Nasby wrote:
> What we really need is a replacement for vacuum_delay that takes
> PostgreSQL generated IO activity into account...
There are also other ideas which can make vacuum less painfull:
- Use a "delete"-map (like the free space map) so vacuum can quickly
find the pages to look at.
- Have vacuum end its transaction after a certain amount of work, and
restart at the same page later.
- Have vacuum full search good candidates with non-stopping lock (and
usage of delete-map and fsm), then doing {lock, recheck, move, unlock}
in small amounts of data with delay between.
- Introducing some load measurement, and a pressure measurement (number
of deleted rows, TID wraparound etc.). Then start vacuum when load is
low or pressure is very high. Tune other parameters (like "certain
amount of work" depending on those measures.
All of them are a lot of code to hack, but although I'm not a postgresql
core developer, I am keen enough to invite you to send patches. :-)
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
