Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] smartvacuum() instead of autovacuum

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-10-23 19:12:07
Subject: Re: New CRC algorithm: Slicing by 8
Previous:From: richard-pgodbcDate: 2006-10-23 19:02:46
Subject: Tsearch2 index size

pgsql-patches by date

Next:From: Peter BrantDate: 2006-10-23 19:24:25
Subject: Re: BUG #2712: could not fsync segment: Permission
Previous:From: Peter BrantDate: 2006-10-23 18:59:39
Subject: Re: BUG #2712: could not fsync segment: Permission

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group