Re: O(n) tasks cause lengthy startups and checkpoints
От | Simon Riggs |
---|---|
Тема | Re: O(n) tasks cause lengthy startups and checkpoints |
Дата | |
Msg-id | CANbhV-FGh4fwQ-f_O_1nmvO1K22bOTYi_nQdL_kTyoZ7HgPTcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: O(n) tasks cause lengthy startups and checkpoints (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, 23 Jun 2022 at 14:46, Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Jun 23, 2022 at 7:58 AM Simon Riggs > <simon.riggs@enterprisedb.com> wrote: > > Having a central cleanup process makes a lot of sense. There is a long > > list of potential tasks for such a process. My understanding is that > > autovacuum already has an interface for handling additional workload > > types, which is how BRIN indexes are handled. Do we really need a new > > process? > > It seems to me that if there's a long list of possible tasks for such > a process, that's actually a trickier situation than if there were > only one or two, because it may happen that when task X is really > urgent, the process is already busy with task Y. > > I don't think that piggybacking more stuff onto autovacuum is a very > good idea for this exact reason. We already know that autovacuum > workers can get so busy that they can't keep up with the need to > vacuum and analyze tables. If we give them more things to do, that > figures to make it worse, at least on busy systems. > > I do agree that a general mechanism for getting cleanup tasks done in > the background could be a useful thing to have, but I feel like it's > hard to see exactly how to make it work well. We can't just allow it > to spin up a million new processes, but at the same time, if it can't > guarantee that time-critical tasks get performed relatively quickly, > it's pretty worthless. Most of the tasks mentioned aren't time critical. I have no objection to a new auxiliary process to execute those tasks, which can be spawned when needed. -- Simon Riggs http://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: