Re: autovacuum and reloptions

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum and reloptions
Date: 2009-02-06 02:25:47
Message-ID: 498B9FAB.8040002@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera escreveu:
> So here's what looks like a committable patch.
>
> Note to self: remember to remove src/include/catalog/pg_autovacuum.h and
> to bump catversion.
>
>
Works for me. Just a few comments.

(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";

(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";

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

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

--
Euler Taveira de Oliveira
http://www.timbira.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2009-02-06 02:49:56 Re: Synch Replication
Previous Message Robert Haas 2009-02-06 01:27:07 Re: new GUC var: autovacuum_process_all_tables