Re: autovacuum and reloptions

Euler Taveira de Oliveira escribió:

> (i) I don't like this construction "by entries by changing storage
> parameters". I prefer "by changing storage parameters" or "by entries in
> pg_class.reloptions";

Heh, obvious "by entries by" is a cut'n'pasto; fixed.

Maybe an xref would be better there.  I attach the doc patch again; I
fiddled a bit with it this morning.  Comments?

> (ii) I think we should change the expression "storage parameters" for
> something else because autovacuum is related to maintenance. My suggestion is
> a general expression like "relation parameters";

I'm not sure I agree with this idea, because the term "storage
parameter" has been used for several releases already.  This would be a
relatively major terminology change.

> (iii) I noticed that GUC defaults and relopt defaults are different
> (autovacuum_cost_delay and autovacuum_cost_limit). Is there any reason for not
> using -1?

Yeah, -1 does not make sense.  It made sense in pg_autovacuum because
otherwise you didn't have to specify "skip this setting and use the
default".  In reloptions, if you don't want to specify the setting, just
don't specify it.

> (iv) Maybe we should document that pg_dump will only dump reloptions like
> toast.foo iff the relation has an associated TOAST table. This seems obvious
> but ...

Well, if it doesn't have a toast table, then there's no need for toast
settings, is there?  I mean, you could construe it as a gotcha: if you
CREATE TABLE with only fixed-length columns and specify some reloptions,
and later add a column that requires a toast table, it won't have the
options you set at CREATE time.  However, it seems to me to be very low
in the importance scale.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.