Matthew T. O'Connor wrote:
> Fair point, my only concern is that a backend integrated
> pg_autovacuum would be radically different from the current libpq
> based client application.
Unfortunately, a "configurable-via-tables" pg_autovacuum is also going
to be quite different from the current "unconfigurable" version.
If we were to make it configurable, I would suggest doing so via
specifying a database and schema into which it would then insert a set
of tables to provide whatever information was considered worth
'fiddling' with.
But at that point, it makes sense to add in quite a bit of
"configurable" behaviour, such as:
-> Specifying that certain tables should _never_ be automatically
vacuumed.
-> Establishing a "queue" of tables that pg_autovacuum plans to
vacuum, so that users could add in desired vacuums ("after the
other stuff being handled, force in a vacuum of app_table_foo").
That way, vacuums can be 'forced in' without introducing the
possibility that multiple vacuums might be done at once...
-> Making information about what vacuums have been done/planned
persistent across runs of pg_autovacuum, and even across
shutdowns of the DBMS.
This changes behaviour enough that I'm not sure it's the same
"program" as the unconfigurable version. Almost every option would be
substantially affected by the logic:
if (CONFIG_DATA_IN_DB) {
/* Logic path that uses data in Vacuum Schema */
} else {
/* More banal logic */
}
If I can store configuration in the database, then I'd like to also
make up a view or two, and possibly even base the logic used on views
that combine configuration tables with system views. In effect, that
makes for a _third_ radically different option.
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
