Re: reloption to prevent VACUUM from truncating empty pages at theend of relation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Date
Msg-id 20190304214350.jwzuktvrgn3qzzlc@alap3.anarazel.de
Whole thread Raw
In response to Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
List pgsql-hackers
Hi,

On 2019-03-04 21:40:53 +0000, Bossart, Nathan wrote:
> On 3/4/19, 12:11 PM, "Andres Freund" <andres@anarazel.de> wrote:
> > I'm not quite convinced this is right.  There's plenty sites that
> > practically can't use autovacuum because it might decide to vacuum the
> > 5TB index because of 300 dead tuples in the middle of busy periods.  And
> > without an reloption that's not controllable.
>
> Wouldn't it be better to adjust the cost and threshold parameters or
> to manually vacuum during quieter periods?

No. (auto)vacuum is useful to reclaim space etc. It's just the
unnecessary index cleanup that's the problem...  Most of the space can
be reclaimed after all, the item pointer ain't that big...


> I suppose setting DISABLE_INDEX_CLEANUP on a relation during busy
> periods could be useful if you really need to continue reclaiming
> transaction IDs, but that seems like an easy way to accidentally never
> vacuum indexes.

Yea, I do think that's a danger. But we allow disabling autovacuum, so
I'm not sure it matters that much... And for indexes you'd still have
the index page-level vacuum that'd continue to work.

- Andres


pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Next
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons