Skip site navigation (1) Skip section navigation (2)

Re: Why is vacuum_freeze_min_age 100m?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why is vacuum_freeze_min_age 100m?
Date: 2009-08-12 21:22:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
>> (2) there's not really much to be gained by reducing it.
> That depends.  The backup techniques I recently posted, using hard
> links and rsync, saved us the expense of another ten or twenty TB of
> mirrored SAN archival storage space, and expensive WAN bandwidth
> upgrades.  In piloting this we found that we were sending our
> insert-only data over the wire twice -- once after it was inserted and
> once after it aged sufficiently to be frozen.  Aggressive freezing
> effectively cut our bandwidth and storage needs for backup down almost
> by half.  (Especially after we made sure we left enough time for the
> VACUUM FREEZE to complete before starting that night's backup
> process.)

Hmmm ... if you're using VACUUM FREEZE, its behavior is unaffected by
this GUC anyway --- that option makes it use a freeze age of zero.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Kevin GrittnerDate: 2009-08-12 21:33:44
Subject: Re: Why is vacuum_freeze_min_age 100m?
Previous:From: Kevin GrittnerDate: 2009-08-12 18:17:05
Subject: Re: Why is vacuum_freeze_min_age 100m?

pgsql-hackers by date

Next:From: Pierre Frédéric CaillaudDate: 2009-08-12 21:28:53
Subject: Re: COPY speedup
Previous:From: Stephen FrostDate: 2009-08-12 20:48:24
Subject: Re: WIP: getting rid of the pg_database flat file

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group