Re: new GUC var: autovacuum_process_all_tables

>> AIUI, the main reason for table groups would be to define different
>> autovacuum policies for different groups of tables.  Right now, that
>> would be pretty stupid, because there are only two possible policies:
>> "yes" and "no".
>
> not really... the idea is to let one group to have autovacuum on in
> certain periods of time and let them of the rest of the time...

Yes, but that's a future enhancement, we don't have that now.

> or maybe a group of tables should be autovacuumed every 50 updates
> (vac_base_thresh) and some tables every 100, in some hours maybe we
> need to have different vac_cost_delay and vac_cost_limit...
>
> actually there are different parameters that could be set...
>
>> Instead, you're going to want to define it once and then point
>> individual tables at it.  But you could do that just as well by
>> assigning each policy a name or number and then setting a reloption on
>> the table to refer to that name or number, which would completely
>> avoid the need to invent all-new, non-standard syntax.
>
> well the reloptions *is* invented and non-standard syntax

Yes, but we already have that one.  IMO we should try to reuse it and
only invent new stuff if there is a compelling reason - which is so
far absent from this discussion.

>> But if we do decide to invent such a syntax, it's not good enough to
>> say that we should make it general because it might be useful for a
>> purpose other than autovacuum.  We should have a pretty specific idea
>> of what sort of purpose that might be.  Otherwise, we'll likely find
>> (when the purpose finally arises) that the supposedly-general model we
>> introduced doesn't fit it as well as we thought.
>>
>> But right now, we don't even have ONE use case for the general syntax,
>> let alone two, because the future autovacuum enhancements that would
>> make use of that syntax haven't been designed yet (or at least haven't
>> been discussed here yet).
>
>
> --- devil's advocate mode on ---
>
> a general purpose scheduler could be used for:
> - REINDEX
> - moving data around for OLAP
> - periodically execute SP that has to change the status of a process
> in a time driven way...
> - autovacuum, and programming manual vacuums
>
> --- devil's advocate mode off ---

AFAICS, table groups wouldn't help with any of that stuff.  I think
you're proving my point that we have no idea what we're implementing,
so it's a little premature to talk about what else the same
infrastructure can be used for.

> now, we actually can do that work with external schedulers (cron in
> linux, the windows task scheduler, etc)... the only two reasons i can
> think to prefer our own sintax for this is: pg_dump support to keep
> pilicies alive even in a fresh installed machine and marketing (two
> good reasons if you ask me)

Which are all great points, but not what I was talking about.  I am
talking about the table group stuff.

...Robert