Re: PITR performance overhead?

If your server is heavily I/O bound AND you care about your data AND your
are throwing out your WAL files in the middle of the day...  You are headed
for a cliff.

I'm sure this doesn't apply to anyone on this thread, just a general
reminder to all you DBA's out there who sometimes are too busy to implement
PITR until after a disaster strikes.   I know that in the past I've
personally been guilty of this on several occasions.

--Denis
  EnterpriseDB (yeah, rah, rah...)

On 8/1/06, Merlin Moncure <mmoncure@gmail.com> wrote:
>
> On 8/1/06, George Pavlov <gpavlov@mynewplace.com> wrote:
> > I am looking for some general guidelines on what is the performance
> > overhead of enabling point-in-time recovery (archive_command config) on
> > an 8.1 database. Obviously it will depend on a multitude of factors, but
> > some broad-brush statements and/or anecdotal evidence will suffice.
> > Should one worry about its performance implications? Also, what can one
> > do to mitigate it?
>
> pitr is extremely cheap both in performance drag and administation
> overhead for the benefits it provides.  it comes almost for free, just
> make sure you can handle all the wal files and do sane backup
> scheduling.  in fact, pitr can actually reduce the load on a server
> due to running less frequent backups.  if your server is heavy i/o
> loaded, it might take a bit of planning.
>
> merlin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org
>