Re: Increase Vacuum ring buffer.

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.

In response to

Responses

Browse pgsql-hackers by date

  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