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: | 7454.1250112131@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre Frédéric Caillaud | 2009-08-12 21:28:53 | Re: COPY speedup |
Previous Message | Stephen Frost | 2009-08-12 20:48:24 | Re: WIP: getting rid of the pg_database flat file |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-08-12 21:33:44 | Re: Why is vacuum_freeze_min_age 100m? |
Previous Message | Kevin Grittner | 2009-08-12 18:17:05 | Re: Why is vacuum_freeze_min_age 100m? |