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: 4A82C0D10200002500029977@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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
process.)

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.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

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

Browse pgsql-performance by date

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