Re: a vacuum thread is not the answer

On Thu, 2002-03-07 at 20:15, mlw wrote:
> I was just toying around with things, and you know, running vacuum in the
> background doesn't work. It slows things down too much.
>
> The worst case senario is when one does this:
>
> update accounts set abalance = abalance + 1 ;
>
> This takes forever to run and doubles the size of the table.

How is this related to running vacuum in background ?

Does it run fast when vacuum is not running ?

> Is there a way that a separate thread managing the freelist can perform a "per
> row" vacuum concurrently? Maybe I am stating the problem incorrectly, but we
> need to be able to recover rows already in memory for performance.

What could be possibly done (and is probably not very useful anyway) is
reusing the row modified _in_the_same_transaction_ so that

begin;
abalance = abalance + 1 ;
abalance = abalance + 1 ;
abalance = abalance + 1 ;
end;

would consume just 2x the tablespace and not 4x. But this does not
require a separate thread, just some changes in update logic.

OTOH, this will probably interfere with some transaction modes that make
use of command ids.

--------------
Hannu