The world rejoiced as [EMAIL PROTECTED] (Hannu Krosing) wrote: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.
Christopher Browne kirjutas E, 03.11.2003 kell 02:15:
Well, actually, the case where it _would_ be troublesome would beCan't one just run a _separate_ VACUUM on those smaller tables ?
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.
Yes, but that defeats the purpose of having a daemon that tries to
manage this all for you.
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....
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
