From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Autovacuum loose ends |
Date: | 2005-07-14 19:41:55 |
Message-ID: | 87pstlw4xo.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I was thinking GUC settings only; is there a real use-case for
> table-specific delay parameters? ISTM the point of the delay parameters
> for autovac is to put a lid on its impact on interactive response. Seen
> in that light, you do not care exactly which table it's hitting at the
> moment.
I'm not sure that's true.
ISTM if you have a small table that needs to be vacuumed frequently you
probably don't want it taking longer than necessary to vacuum. It's probably
mostly cached so there wouldn't be much of an i/o hit and even a small sleep
can make a big proportional difference in vacuum run time. You could get into
a situation where it takes longer to vacuum a bunch of such tables than the
frequency you need the vacuuming to taking place.
I think the i/o problem comes when you have large uncached tables. They
probably have a relatively small percentage of the table being updated and so
don't need to be vacuumed frequently. But when they do you need the sleeps to
avoid the i/o problems.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2005-07-14 19:44:18 | Re: [PATCHES] O_DIRECT for WAL writes |
Previous Message | Greg Stark | 2005-07-14 19:34:32 | Re: [PATCHES] O_DIRECT for WAL writes |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2005-07-14 19:44:18 | Re: [PATCHES] O_DIRECT for WAL writes |
Previous Message | Greg Stark | 2005-07-14 19:34:32 | Re: [PATCHES] O_DIRECT for WAL writes |