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: 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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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