"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> Shortly after I kicked it off, I watched the number of connections
> trend upward as a result of the aggressive locking of FULL. I didn't
> want to let this continue without notifying the developers about a
> potential downtime for their application, so I killed the vacuumdb
> process I had started, figuring that the existing connections would
> go right through.
Killing the vacuumdb client process wouldn't automatically abort the
current operation of the connected backend. If that's all you did,
it would've finished out the VACUUM command, ie, essentially no effect.
Sending a SIGINT to the backend to cancel the current command would've
been the right thing to do.
> Can autovacuum recover for the months where
> the FSM settings were not sufficient to cover the number of relations
> in this cluster?
Probably not. But VACUUM FULL isn't really a great choice either;
it will certainly do nothing at all for index bloat. You might try
CLUSTER instead if you need to aggressively recover space.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
