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

Re: Why is vacuum_freeze_min_age 100m?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why is vacuum_freeze_min_age 100m?
Date: 2009-08-12 18:17:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
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
Not that most people have the same issue, but there are at least
*some* situations where there is something significant to be gained by
aggressive freezing.  Not that this is an argument for changing the
*default*, of course; if someone is going to venture into these backup
techniques, they'd better have the technical savvy to deal with
tweaking their freeze strategy.

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2009-08-12 21:22:11
Subject: Re: Why is vacuum_freeze_min_age 100m?
Previous:From: NickolayDate: 2009-08-12 16:24:52
Subject: transaction delays to apply

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-08-12 18:21:49
Subject: Re: WIP: getting rid of the pg_database flat file
Previous:From: Peter EisentrautDate: 2009-08-12 18:13:56
Subject: Re: Alpha 1 release notes

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