Re: Plans for solving the VACUUM problem

Kaare Rasmussen <kar(at)webline(dot)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