Re: Some vacuum & tuning help

On Tue, 2003-08-05 at 17:40, Christopher Browne wrote:
> Unfortunately, a "configurable-via-tables" pg_autovacuum is also going
> to be quite different from the current "unconfigurable" version.

true, however I would like to preserve the "unconfigured" functionality
so that it can be run against a totally unmodified database cluster. If
it finds configuration information on the server then it uses it,
otherwise it just acts as it does now.

> 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.

agreed

> -> 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...

makes sense.

> -> Making information about what vacuums have been done/planned
> persistent across runs of pg_autovacuum, and even across
> shutdowns of the DBMS.

good.

> 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 */
> }

I'm not so sure it's that different. In either case we are going to
have a threshold and decide to vacuum based on that threshold. The
change is only that the data would be persistent, and could be
customized on a per table basis. The logic only really changes if
running unconfigured uses different data than the configured version,
which I don't see as being proposed.

> 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.

Not sure I see what all you are implying here. Please expand on this if
you deem it worthy.

I guess I'll start coding again. I'll send an email to the hackers list
tomorrow evening with as much info / design as I can think of.

Matthew