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(at)gmail(dot)com> wrote:
>
> On 8/1/06, George Pavlov <gpavlov(at)mynewplace(dot)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
>