On Fri, 2003-10-17 at 09:34, Shridhar Daithankar wrote:
> I am slightly confused here. IIRC pg_autovacuum never did a vacuum full.
Correct.
> At the
> most it does vacuum /vacuum analyse,
Incorrect, it either does vacuum analyse, or just analyse
> none of which chew disk bandwidth.
Incorrect, vacuum can have lots of disk I/O, analyze has considerably
less, but still some.
> And if
> pg_autovacuum is running along with postmaster all the time, with aggressive
> polling like 5 sec, the database should not accumulate any dead tuples
True, however, I think such aggressive polling will be a net loss in
efficiency.
> nor it
> would suffer xid wraparound as there are vacuum happening constantly.
Wrong, pg_autovacuum typically just does vacuum [table name], which does
not effect the xid wraparound issue, one has to issue a vacuum against
an entire database to effect that.
> What's left in above scenario? As long as all the requirements for pg_autovacuum
> are met, namely setting it up, setting it up aggressively and tuning
> postgresql.conf correctly, vacuum and related problems should be a thing in
> past, at least as far as 7.4 and onwards is considered.
Well it still remains to be seen if the client side implementation of
pg_autovacuum is sufficient. Also, we will see if index bloat is
handled (less an autovac issue, but semi-related). Ideally, autovac
should make better decisions based on FSM and perhaps even the RSM (is
that what it was called?) that people have talked about setting up.
With all that said, hopefully pg_autovacuum proves to be a successful
experiment, and if so, then it needs to be integrated into core somehow.
Matthew