Re: [PATCHES] smartvacuum() instead of autovacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] smartvacuum() instead of autovacuum
Date
Msg-id 27345.1161630483@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] smartvacuum() instead of autovacuum  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: [PATCHES] smartvacuum() instead of autovacuum  (Matthew O'Connor <matthew@zeut.net>)
Re: [PATCHES] smartvacuum() instead of autovacuum  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> writes:
> The only case I can think of where autovac might not work as well as
> smartvacuum would be if you had a lot of databases in the cluster, since
> autovacuum will only vacuum one database at a time.

It's conceivable that it'd make sense to allow multiple autovac
processes running in parallel.  (The infrastructure part of this is easy
enough, the hard part is keeping them from all deciding to vacuum the
same table.)

One reason we have not done that already is the thought that multiple
vacuum processes would suck too much I/O to be reasonable.  Now you
could dial back their resource demands with the cost-delay settings,
but it's not clear that ten autovacs running at one-tenth speed are
better than one autovac using all the cycles you can spare.  Usually
I think it's best if a vacuum transaction finishes as fast as it can.

In any case, these exact same concerns would apply to manual vacuums
or a combination of manual and auto vacuum.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: New CRC algorithm: Slicing by 8
Next
From: richard-pgodbc@armchair.mb.ca
Date:
Subject: Tsearch2 index size