Re: Cost limited statements RFC

On Thu, Jun 6, 2013 at 1:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> If we can see our way clear to ripping out the autovacuum costing
> stuff and replacing them with a read rate limit and a dirty rate
> limit, I'd be in favor of that. The current system limits the linear
> combination of those with user-specified coefficients, which is more
> powerful but less intuitive. If we need that, we'll have to keep it
> the way it is, but I'm hoping we don't.
>

I don't know what two independent setting would look like. Say you keep
two independent counters, where each can trigger a sleep, and the
triggering of that sleep clears only its own counter. Now you still have a
limit on the linear combination, it is just that summation has moved to a
different location. You have two independent streams of sleeps, but they
add up to the same amount of sleeping as a single stream based on a summed
counter.

Or if one sleep clears both counters (the one that triggered it and the
other one), I don't think that that is what I would call independent
either. Or at least not if it has no memory. The intuitive meaning of
independent would require that it keep track of which of the two counters
was "controlling" over the last few seconds. Am I overthinking this?

Also, in all the anecdotes I've been hearing about autovacuum causing
problems from too much IO, in which people can identify the specific
problem, it has always been the write pressure, not the read, that caused
the problem. Should the default be to have the read limit be inactive and
rely on the dirty-limit to do the throttling?

Cheers,

Jeff