Ron Mayer <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
