"Matthew T. O'Connor" <matthew@zeut.net> writes:
> That patch is a step forward if it's deemed OK by the powers that be.
> However, autovacuum would still need to be taught to handle simultaneous
> vacuums. I suppose that in the interim, you could disable autovacuum
> for the problematic queue table and have cron issue a manual vacuum
> command for that table at the required frequency.
I'm not sure you should think of that as an "interim" solution. I don't
really like the idea of multiple autovacuums running concurrently. ISTM
autovac is intended to be something that lurks in the background and
doesn't take up an unreasonable percentage of your system bandwidth ...
but if there's more than one of them, it's going to be mighty hard to
control the overall load penalty. Plus you have to worry about keeping
them off each others' backs, ie, not all trying to vac the same table at
once. And in a scenario like Csaba's, I think the hotspot tables are
just exactly what they'd all try to vacuum.
For small hotspot tables I think a scheduled vacuum process is just the
thing, whereas autovac is more of a free-lance thing to keep the rest of
your DB in line.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
