"Marc G. Fournier" <[EMAIL PROTECTED]> writes:Just curious, but isn't this one of the key points about pg_autovacuum in the first place? So that you vacuum what needs to be vacuum'd, and not *everything* ... ? Shouldn't the answer to the 'bandwidth issue' change to 'you should install/use pg_autovacuum'?
No, not really, but I think it's much more likely that you'd want to enable vacuum delay for autovacuum-commanded vacuums than vacuums commanded interactively. Or, if you still prefer the old-tech way of performing routine vacuums from a cron script, you'd probably turn on vacuum delay in that cron script.
I think we *should* add to autovacuum a parameter to let it set vacuum_delay for its vacuums, and maybe even default to having it on. But I'm unconvinced we want any delay as the global default.
That sounds like a good idea.
But then again, based on this entire discussion and the fact that unvoluntary vacuum runs during a production servers peak time are the worst thing that can happen, I take it that it was never intended to enable pg_autovacuum by default either and that one has to enable it explicitly in the configuration, right?
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
