Re: new GUC var: autovacuum_process_all_tables

On Mon, Feb 9, 2009 at 12:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Hopefully the grouping of tables is not purely related to AV?
>>
>> Hmm, good question. I was envisioning it only for autovacuum, but it
>> hasn't been vetted on pgsql-hackers.
>
> I think we're in danger of inventing a solution in search of a problem here.
>
> 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...

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

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

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)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157