Re: [HACKERS] Increase Vacuum ring buffer. - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: [HACKERS] Increase Vacuum ring buffer.
Date
Msg-id CAGTBQpZsAGWr8bcLZAqLR87F=B9G4vGSkGXUrqQ9hqhNkYG=ZQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Increase Vacuum ring buffer.  (Sokolov Yura <funny.falcon@postgrespro.ru>)
Responses Re: [HACKERS] Increase Vacuum ring buffer.
List pgsql-hackers
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
<funny.falcon@postgrespro.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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: [HACKERS] Buildfarm failure and dubious coding in predicate.c
Next
From: Julien Rouhaud
Date:
Subject: Re: [HACKERS] segfault in HEAD when too many nested functions call