From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Anton Melser <melser(dot)anton(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: autovacuum blues |
Date: | 2006-11-09 22:42:26 |
Message-ID: | 20061109224226.GO26818@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Anton Melser wrote:
> On 09/11/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> >Anton Melser wrote:
> >
> >> Thanks for that. Just a clarification, can someone tell me what the
> >> "number of tuples" means in the context of the multipliers? I mean,
> >> when the vacuum min multiplier is at 0.4, we multiply 0.4 by what? I
> >> get the min val, but what are we multiplying by 0.4? The total number
> >> of tuples in the table? The total modified/deleted?
> >
> >pg_class.reltuples
>
> So I am still a little unclear... I need to analyse to get relevant
> stats for autovacuum... but autovacuum needs to be used to update the
> relevant stats? Can I REALLY do without a cronjob, or am I just
> thinking wishfully (I can invent expressions if I want!).
This means that we use the previously-known value of tuples in the table, plus
the number of new tuples that have been inserted, deleted and/or updated
(numbers you can see in the pg_stat_* views), and compare them to the
thresholds. If I'm being too unclear, here is the relevant code comment:
* A table needs to be vacuumed if the number of dead tuples exceeds a
* threshold. This threshold is calculated as
*
* threshold = vac_base_thresh + vac_scale_factor * reltuples
*
* For analyze, the analysis done is that the number of tuples inserted,
* deleted and updated since the last analyze exceeds a threshold calculated
* in the same fashion as above. Note that the collector actually stores
* the number of tuples (both live and dead) that there were as of the last
* analyze. This is asymmetric to the VACUUM case.
The idea is that you _can_ do without a cronjob. You may need to do a
first ANALYZE just to get things warmed up, and then let autovacuum do
its job.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-09 23:52:36 | Re: planer picks a bad plan (seq-scan instead of index) when adding an additional join |
Previous Message | Brent Wood | 2006-11-09 21:57:24 | Re: Problem with pg_dump |