From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers-owner(at)postgresql(dot)org |
Subject: | Re: Increase Vacuum ring buffer. |
Date: | 2017-07-21 21:27:42 |
Message-ID: | CAGTBQpZsAGWr8bcLZAqLR87F=B9G4vGSkGXUrqQ9hqhNkYG=ZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
<funny(dot)falcon(at)postgrespro(dot)ru> wrote:
>
> My friend noticed, that I didn't said why I bother with autovacuum.
> Our customers suffers from table bloating. I've made synthetic
> bloating test, and started experiments with modifying micro- and
> auto-vacuum. My first attempts were to update FSM early (both in
> micro and autovacuum) and update it upto root, not only low level.
This FSM thing is probably not a bad idea as well.
We're forced to run regular manual vacuums because for some tables
autovacuums seems to never be enough, no matter how it's configured,
mostly because it gets canceled all the time. These are high-churn,
huge tables, so vacuuming them takes hours or days, there's always
someone with a conflicting lock at some point that ends up canceling
the autovacuum task.
The above paragraph triggered me to go check, and it seems in those
cases the FSM never gets vacuumed. That's probably not a good thing,
but I don't see how to vacuum the FSM after a cancel. So vacuuming the
FSM from time to time during long-running vacuums seems like a good
idea at this point.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2017-07-21 22:25:36 | Re: segfault in HEAD when too many nested functions call |
Previous Message | Tom Lane | 2017-07-21 20:58:29 | Buildfarm failure and dubious coding in predicate.c |