Re: new autovacuum criterion for visible pages - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: new autovacuum criterion for visible pages
Date
Msg-id CAMkU=1xO13r8MDNaP0ih6F9hvjCUZzfBrwueb97Mn85kG32W2A@mail.gmail.com
Whole thread Raw
In response to Re: new autovacuum criterion for visible pages  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: new autovacuum criterion for visible pages  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: new autovacuum criterion for visible pages  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: new autovacuum criterion for visible pages  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> I wanted to create a new relopt named something like
>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>> vacuum a table once less than a certain fraction of the relation's
>> pages are marked allvisible.
>>
>
> Why would it more convenient for a user to set such a parameter as
> compare to existing parameters (autovacuum_vacuum_threshold +
> autovacuum_vacuum_scale_factor)?

Insertions and HOT-updates clear vm bits but don't increment the
counters that those existing parameters are compared to.

Also, the relationship between number of updated/deleted rows and the
number of hint-bits cleared can be hard to predict due to possible
clustering of the updates into the same blocks.  So it would be hard
to know what to set the values to.

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Patch] New psql prompt substitution %r (m = master, r = replica)
Next
From: Robert Haas
Date:
Subject: Re: No longer possible to query catalogs for index capabilities?