Re: new GUC var: autovacuum_process_all_tables

On Mon, Feb 9, 2009 at 1:44 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> 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.
>

that was what simon was talking about, IIRC... he was speculating
about a possible future syntax for grouping tables for use with a
possible future postgres scheduler...

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

reloptions is what we will use for autovacumm (actually Alvaro already
applied that patch)... no one is touching that... the group syntax is
for a future feature...

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

table groups are not being implemented now... it was a mere
speculation about a way to apply a policy in a set of tables...
actually, Alvaro's response was: "something like that" so we have to
actually wait for his proposal before start a war on that and before
we think it could be general enough to include other policies (like
the ones for an scheduler)

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

that's because we are not implementing that now... it's for the future...

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

me too


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