Re: Vacuum, Freeze and Analyze: the big picture - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Vacuum, Freeze and Analyze: the big picture
Date
Msg-id 20130530200709.GJ14029@awork2.anarazel.de
Whole thread Raw
In response to Re: Vacuum, Freeze and Analyze: the big picture  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 2013-05-30 12:18:29 -0700, Josh Berkus wrote:
> 
> > If we have reason to vacuum the relation we do it at
> > vacuum_freeze_table_age, not only at autovacuum_max_freeze_age. The
> > difference is that the latter triggers a vacuum, while the former only
> > changes a partial vacuum into a full one.
> > 
> > Calling that behaviour unconditionally worse is, err, interesting...
> 
> *overall* it's better.  But as far as FREEZE itself is concerned, it's
> worse.

I am not trying to give you a hard time, but I really can't follow. In
<8.3 we only froze tuples that were older than vacuum_freeze_min_age,
just as today (although the default was higher then than today). 100mio
transactions is long enough that you almost guaranteedly be in a
different checkpoint cycle when freezing than when initially writing the
tuple's buffer. So independent of the time the buffer is frozen (be it
a) we always scan the whole relation, b) we have a partial vacuum
upgraded to a full one due to vacuum_freeze_table_age c) an anti
wraparound vacuum) we will usually write a buffer multiple times.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries
Next
From: Bruce Momjian
Date:
Subject: Re: Freezing without write I/O