> The case I'm looking at is a large table which requires a lazy vacuum,
> and a zero vacuum cost delay would cause too much I/O. Yet, this
> table has enough insert/delete activity during a vacuum, that it
> requires a fairly frequent analysis to maintain proper plans. I
> patched as mentioned above and didn't run across any unexpected
> issues; the only one expected was that mentioned by Alvaro.
I don't find this a compelling argument, at least not without proof that
the various vacuum-improvement projects already on the radar screen
(DSM-driven vacuum, etc) aren't going to fix your problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment