From: "Christopher Browne" <cbbrowne@libertyrms.info>
> Shridhar Daithankar wrote:
> > I agree, specifying per table thresholds would be good in autovacuum..
>
> Which begs the question of what the future direction is for pg_autovacuum.
This is a good question.
> There would be some merit to having pg_autovacuum throw in some tables
> in which to store persistent information
As long as pg_autovacuum is either a contrib module, or not integrated into
the backend, we can't do this. I don't think we should require that tables
are added to your database in order to run pg_autovacuum, I have thought
that a "helper table" could be used, this table, if found by pg_autovacuum
would use it for per table defaults, exclusion list etc.... That way
pg_autovacuum can run without a polluted database, or can be tuned.
If pg_autovacuum in made official, moves out of contrib and becomes a core
tool, then we can either add columns to some system catalogs to track this
information or add a new system table.
> All well and interesting stuff that could be worth implementing.
>
> But the usual talk has been about ultimately integrating the
> functionality into the backend, making it fairly futile to enhance
> pg_autovacuum terribly much.
>
> Unfortunately, the "integrate into the backend" thing has long seemed
> "just around the corner." I think we should either:
> a) Decide to enhance pg_autovacuum, or
> b) Not.
I have been talking about "integraging it into the backend" for a while, and
I used to think it was "just around the corner" unfortunately, work
schedule and my C skills have prevented me from getting anything useful
working. If you would like to work on it, I would help as much as possible.
I chose to leave pg_autovacuum simple and not add too many features because
the core team has said that it needs to be integrated into the backend
before it can be considered a core tool.
ps, please cc me as I'm not subscribed to the list.
