| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Autovacuum and Autoanalyze |
| Date: | 2008-09-17 07:09:13 |
| Message-ID: | 48D0AD19.50100@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Fetter wrote:
> On Tue, Sep 16, 2008 at 08:59:08PM -0400, Alvaro Herrera wrote:
>> Simon Riggs wrote:
>>> Disabling autovacuum can have catastrophic effects, since it disables
>>> the ANALYZing of tables.
>>>
>>> Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
>> You mean something like
>> autovacuum = on / off / analyze ?
>>
>> We can certainly do that, but is there buy-in?
>
> +1
>
> Having autovacuum on during bulk loads can really tank performance,
> but having autoanalyze on is good :)
Isn't autoanalyze a waste of time during a bulk load? Seems better to
run ANALYZE manually at the end.
Adding that option feels natural to me, but it is a rather blunt
instrument. You can already do that with pg_autovacuum, though that
interface isn't very user-friendly. I whole-heartedly support the idea
of controlling autovacuum with storage options, e.g "ALTER TABLE ...
WITH (autoanalyze = on)".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2008-09-17 08:06:50 | Re: New FSM patch |
| Previous Message | KaiGai Kohei | 2008-09-17 06:28:05 | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |