From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Hitoshi Harada <hitoshi_harada(at)forcia(dot)com>, "'Peter Eisentraut'" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] smartvacuum() instead of autovacuum |
Date: | 2006-10-23 19:08:03 |
Message-ID: | 27345.1161630483@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Jim C. Nasby" <jim(at)nasby(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-23 19:12:07 | Re: New CRC algorithm: Slicing by 8 |
Previous Message | richard-pgodbc | 2006-10-23 19:02:46 | Tsearch2 index size |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Brant | 2006-10-23 19:24:25 | Re: BUG #2712: could not fsync segment: Permission |
Previous Message | Peter Brant | 2006-10-23 18:59:39 | Re: BUG #2712: could not fsync segment: Permission |