Christopher Browne wrote:
>The world rejoiced as hannu@tm.ee (Hannu Krosing) wrote:
>
>
>>Christopher Browne kirjutas E, 03.11.2003 kell 02:15:
>>
>>
>>>Well, actually, the case where it _would_ be troublesome would be
>>>where there was a combination of huge tables needing vacuuming and
>>>smaller ones that are _heavily_ updated (e.g. - account balances),
>>>where pg_autovacuum might take so long on some big tables that it
>>>wouldn't get to the smaller ones often enough.
>>>
>>>
>>Can't one just run a _separate_ VACUUM on those smaller tables ?
>>
>>
>
>Yes, but that defeats the purpose of having a daemon that tries to
>manage this all for you.
>
>
But if this delayed vacuum was available for pg_autovacuum to use, it
might be useful for pg_autovacuum to run multiple simultaneous vacuums.
It seems to me that the delayed vacuum is so slow, that we could
probably run several (a few) of them without saturating the I/O.
Or... It seems to me that we have been observing something on the order
of 10x-20x slowdown for vacuuming a table. I think this is WAY
overcompensating for the original problems, and would cause it's own
problem as mentioned above. Since the granularity of delay seems to be
the problem can we do more work between delays? Instead of sleeping
after every page (I assume this is what it's doing) perhaps we should
sleep every 10 pages, or perhaps fix the sleep value at 10ms and make
the amount of work done between sleeps a configurable option. Seems
that would allow small tables to be done without delay etc....
