Re: Autovacuum loose ends

Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> Tom Lane wrote:
>> 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.

> Unless the table in question takes a big lock when it's VACUUMed
> like tables with GiST indexes do today.

Well, the issue there is not at the table level, but only while the
individual index is being cleaned.

I suggested a few days ago that we ought not do vacuum delays at all
while processing an index that needs an exclusive lock (this no longer
includes gist, but rtree and to a lesser extent hash still have issues).

If you don't like that, I think you'd pretty much have to invent autovac
delays that are tunable on a *per index* basis, not per table. That
seems a bit over the top to me; it'd be a nontrivial amount of work to
implement, and there's no evidence that it's better than just removing
the vacuum_delay_point calls in rtree and hash.

regards, tom lane