Re: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Plans for solving the VACUUM problem
Date
Msg-id 29858.990283453@sss.pgh.pa.us
Whole thread Raw
In response to Re: Plans for solving the VACUUM problem  (Kaare Rasmussen <kar@webline.dk>)
List 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 by date:

Previous
From: mlw
Date:
Subject: Re: External search engine, advice
Next
From: Tom Lane
Date:
Subject: Re: Fix for tablename in targetlist