Re: [HACKERS] More detail on settings for pgavd? - Mailing list pgsql-performance

From Josh Berkus
Subject Re: [HACKERS] More detail on settings for pgavd?
Date
Msg-id 200311211349.58788.josh@agliodbs.com
Whole thread Raw
In response to Re: [HACKERS] More detail on settings for pgavd?  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: [HACKERS] More detail on settings for pgavd?
List pgsql-performance
Matthew,

> Basically, I don't like the idea of modifying users databases, besides,
> in the long run most of what needs to be tracked will be moved to the
> system catalogs.  I kind of consider the pg_autvacuum database to
> equivalent to the changes that will need to be made to the system catalogs.

OK.  As I said, I don't feel strongly about it.

> I certainly agree that less than 10% would be excessive, I still feel
> that 10% may not be high enough though.   That's why I kinda liked the
> sliding scale I mentioned earlier, because I agree that for very large
> tables, something as low as 10% might be useful, but most tables in a
> database would not be that large.

Yes, but I thought that we were taking care of that through the "threshold"
value?

A sliding scale would also be OK.   However, that would definitely require a
leap to storing per-table pg_avd statistics and settings.

> Only that pg_autovacuum isn't smart enough to kick off more than one
> vacuum at a time.  Basically, pg_autovacuum issues a vacuum on a table
> and waits for it to finish, then check the next table in it's list to
> see if it needs to be vacuumed, if so, it does it and waits for that
> vacuum to finish.

OK, then, we just need to detect the condition of the vacuums "piling up"
because they are happening too often.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco


pgsql-performance by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: [HACKERS] More detail on settings for pgavd?
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: [HACKERS] More detail on settings for pgavd?