Re: autovacuum not prioritising for-wraparound tables

On Wed, Jan 30, 2013 at 5:39 AM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>
>> Don't think I did. I was talking about vacuum_freeze_table_age
>> because that influences the amount of full-table scans
>
> Not any more than vacuum_freeze_min_age does.

There is a lot more room for vacuum_freeze_table_age to be increased,
then there is for vacuum_freeze_min_age to be decreased.

> http://www.postgresql.org/docs/9.2/interactive/routine-vacuuming.html#AUTOVACUUM
>
> | a whole table sweep is forced if the table hasn't been fully
> | scanned for vacuum_freeze_table_age minus vacuum_freeze_min_age
> | transactions.

Why is vacuuming described as such a violent process? It doesn't
"force" a table sweep, it just goes ahead and performs one. In
general, it seems hard to tell from the docs that this only promotes a
vacuum which is going to happen anyway from a vm one to a full scan
one. The forcefulness makes it sound more like it is doing vacuums
that wouldn't happen otherwise (like autovacuum_freeze_max_age does,
which actually could be described as "force" since it turns on the
autovac launcher even if it is configured to be off)

> So reducing vacuum_freeze_min_age not only helps minimize the
> writes that are needed when autovacuum needs to scan the entire
> heap,

How does it do that? If the tuple doesn't need to frozen now because
it was already frozen, that just means the write happened at a
different time but it still happened.

Cheers,

Jeff