Re: Some thoughts about i/o priorities and throttling vacuum

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Maybe in this case it's best to do a VACUUM FREEZE; that'd ensure that
> the table would never ever need a vacuum again until it suffers
> an insert, delete or update.

But how would you keep track of that? Certainly an external autovacuum
daemon couldn't know for sure that the table had never been modified
since it was frozen. I suppose you could think about altering the
backend to mark a table "dirty" whenever an insert/update/delete is
done, but I'd have to think this would be a net waste of cycles in the
vast majority of cases. How many people have tables that are *really*
read-only over the long haul (billions of transactions)?

I think the existing approach of forcing a database-wide vacuum every
billion or so transactions is probably the most efficient way of dealing
with the issue. It's almost certainly cheaper, net, than any scheme
that adds even a tiny overhead to each individual insert/update/delete.

regards, tom lane