Mindaugas Riauba wrote:
The "vacuum cost" parameters can be adjusted to make vacuums fired
by pg_autovacuum less of a burden. I haven't got any specific numbers
to suggest, but perhaps someone else does.
It looks like that not only vacuum causes our problems. vacuum_cost
seems to lower vacuum impact but we are still noticing slow queries "storm".
We are logging queries that takes >2000ms to process.
And there is quiet periods and then suddenly 30+ slow queries appears in
log within the same second. What else could cause such behaviour? WAL log
switch? One WAL file seems to last <1 minute.
How long are these quite periods? Do the "strom" periods correspond to pg_autovacuum loops? I have heard from one person who had LOTS of databases and tables that caused the pg_autovacuum to create a noticable load just updateing all its stats. The solution in that case was to add a small delay insidet the inner pg_autovacuum loop.
---------------------------(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
