ITAGAKI Takahiro wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> wrote:
>> What is this based on? That is, based on what information is it
>> deciding to reduce the naptime?
>
> If there are some vacuum or analyze jobs, the naptime is shortened
> (i.e, autovacuum is accelerated). And if there are no jobs, the naptime
> is lengthened (autovacuum is decelerated).
Yeah, I looked through the patch after I sent this email. It's an
interesting perspective, but I want to see some performance numbers or
significant bloat reduction before I agree this is a good idea. Again,
when a table is busy, constant vacuuming will help keep down bloat, but
at the expense of throughput.
> I noticed my method is based on different views from contrib/pg_autovacuum.
> I'm afraid of the lack of vacuum by autovacuum. So if the database seems to
> require frequent vacuums, I'll accelerate autovacuum, and vice versa.
> If we have a small heavily-updated table and a large rarely-updated table,
> we should vacuum the small one soon after vacuum on the large one is done,
> even if the large vacuum takes long time. -- but hmm, it may be better to
> have multiple autovacuums in such a case primarily.
Yes, I think we are heading in this direction. As of 8.2 PostgreSQL
will allow multiple vacuums at the same time (just not on the same
table), autovacuum hasn't been trained on this yet, but I think it will
eventually.
> I agree. We can use autovacuum thresholds and cost-delay parameters to
> control the frequency and priority of vacuum. I don't think it is good
> to control vacuums by changing naptime.
Now I'm confused, are you now saying that you don't like the concept
behind your patch? Or am I misunderstanding. I think your idea might
be a good one, I'm just not sure yet.
Matt