Phil Endecott wrote:
Matthew T. O'Connor wrote:
Indeed you have. I have head a few similar reports but perhaps none
as bad as yours. One person put a small sleep value so that it
doesn't spin so tight. You could also just up the sleep delay so
that it doesn't do this work quite so often. No other quick
suggestions.
I do wonder why autovacuum is keeping its table list in memory rather
than in the database.
For better or worse, this was a conscious design decision that the
contrib version of autovacuum be non-invasive to your database.
But given that it is keeping it in memory, I think the real fix is to
sort that list (or keep it ordered when building or updating it). It
is trivial to also get the query results ordered, and they can then be
compared in O(n) time.
I'm quite sure there is a better way, please submit a patch if you can.
This was never a real concern for most people since the number of tables
is typically small enough not to be a problem. The integrated version
of autovacuum that didn't make the cut before 8.0 avoids this problem
since the autovacuum data is stored in the database.
I notice various other places where there seem to be nested loops,
e.g. in the update_table_list function. I'm not sure if they can be
fixed by similar means.
I would think so, they all basically do the same type of loop.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
