From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Vacuum, Freeze and Analyze: the big picture |
Date: | 2013-05-30 20:07:09 |
Message-ID: | 20130530200709.GJ14029@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-05-30 21:06:11 | Re: Freezing without write I/O |
Previous Message | Alexander Korotkov | 2013-05-30 19:25:00 | Re: Behavior of a pg_trgm index for 2 (or < 3) character LIKE queries |