Re: Plans for solving the VACUUM problem
От | Tom Lane |
---|---|
Тема | Re: Plans for solving the VACUUM problem |
Дата | |
Msg-id | 29858.990283453@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Plans for solving the VACUUM problem (Kaare Rasmussen <kar@webline.dk>) |
Список | pgsql-hackers |
Kaare Rasmussen <kar@webline.dk> writes: >> Second: if VACUUM can run in the background, then there's no reason not >> to run it fairly frequently. In fact, it could become an automatically >> scheduled activity like CHECKPOINT is now, or perhaps even a continuously >> running daemon (which was the original conception of it at Berkeley, BTW). > Maybe it's obvious, but I'd like to mention that you need some way of > setting priority. No, you don't --- or at least it's far less easy than it looks. If any one of the backends gets niced, then you have a priority inversion problem. That backend may be holding a lock that other backends want. If it's not running because it's been niced, then the other backends that are not niced are still kept from running. Even if we wanted to implement priority inversion detection (painful for locks, and completely impractical for spinlocks), there wouldn't be anything we could do about it: Unix doesn't allow non-root processes to reduce their nice setting. Obviously any automatically-scheduled VACUUM would need some kind of throttling mechanism to keep it from running constantly. But that's not a priority setting. regards, tom lane
В списке pgsql-hackers по дате отправления: