Hi,
On 2019-02-19 20:34:25 +0100, Tomas Vondra wrote:
> On 2/19/19 8:22 PM, Andres Freund wrote:
> > And my main point is that even if you implement a proper bytes/sec limit
> > ONLY for WAL, the behaviour of VACUUM rate limiting doesn't get
> > meaningfully more confusing than right now.
> >
>
> So, why not to modify autovacuum to also use this approach? I wonder if
> the situation there is more complicated because of multiple workers
> sharing the same budget ...
I think the main reason is that implementing a scheme like this for WAL
rate limiting isn't a small task, but it'd be aided by the fact that
it'd probably not on by default, and that there'd not be any regressions
because the behaviour didn't exist before. I contrast, people are
extremely sensitive to autovacuum behaviour changes, even if it's to
improve autovacuum. I think it makes more sense to build the logic in a
lower profile case first, and then migrate autovacuum over it. Even
leaving the maturity issue aside, reducing the scope of the project into
more bite sized chunks seems to increase the likelihood of getting
anything substantially.
Greetings,
Andres Freund
