Re: another autovacuum scheduling thread
| От | Sami Imseih |
|---|---|
| Тема | Re: another autovacuum scheduling thread |
| Дата | |
| Msg-id | CAA5RZ0uf31FQ41udQGL91sp3GdaLqcbwO103Q-zJQcJowq7fEw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: another autovacuum scheduling thread (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: another autovacuum scheduling thread
|
| Список | pgsql-hackers |
> I do think re-prioritization is worth considering, but IMHO we should leave > it out of phase 1. I think it's pretty easy to reason about one round of > prioritization being okay. The order is completely arbitrary today, so how > could ordering by vacuum-related criteria make things any worse? While it’s true that the current table order is arbitrary, that arbitrariness naturally helps distribute vacuum work across tables of various sizes at a given time The proposal now is by design forcing all the top bloated table, that will require more I/O to vacuum to be vacuumed at the same time, by all workers. Users may observe this after they upgrade and wonder why their I/O profile changed and perhaps slowed others non-vacuum related processing down. They also don't have a knob to go back to the previous behavior. Of course, this behavior can and will happen now, but with this prioritization, we are forcing it. Is this a concern? -- Sami Imseih Amazon Web Services (AWS)
В списке pgsql-hackers по дате отправления: