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.